Literature

I gathered you some links you should read:

• The manual on reliability
• The wiki pretty much sums up what's written in the manual, but maybe it helps you too
• You can read a more detailed list of accessible sync methods on this page
• Here are some more or less practical tips in what to choose

Possible Workflow

Basically your workflow might be the following, which is extracted as a combination of all tips of the above links:

1. Turn on postgres setting fsync if it is not.
2. Set synchronous_commit to "on" (or "local") if it is set to "off".
3. Run diskchecker.pl just for sanity to see if you bought something good and it is configured correctly.
4. See what sync method postgres selected automatically with show wal_sync_method;
5. Run pg_test_fsync
6. and use it's output to
   1. check if you are affected by FLUSH CACHE EXT/SYNCHRONIZE CACHE problem.
   2. decide on the basis of the additional information provided here (in paragraph wal_sync_method) and here (in paragraph test_fsync and below) what value to set wal_sync_method to.
7. Check if your BBU and file-system prohibit partial writes of 8kb pages, if yes you may disable full_page_writes (see last paragraph here).

Remark (why this might not be enough)

Note that this seems very reliable, but quoted from one of the links above:

Critics of the battery backup approach suggest that if you run such a system under load, eventually you’ll have a failure in this relatively complicated cache method that will corrupt your database in a way that’s nearly impossible to detect or recover from.

So even having a BBU and a correctly configured server instance, this does not remove the burden to backup everything regularly, and does not remove the possibility to loose some data.

Legal Note

I am not responsible for any lost data ;) neither due to lack of advice here or a wrong tip, nor through anything else.

Since the selective predicate on the big table eav_value_text_data big table is v.value = 'rs145368920', you need an index on value more than anything else. The index on attribute is hardly relevant - only in combination with the first to allow index-only scans if possible:

CREATE INDEX eav_value_text_data_val_att_idx ON eav_value_text_data (value, attribute);

This should make a huge difference.
value should be the first column in the index. More:

• Is a composite index also good for queries on the first field?

Index md5 hash as uuid

Since it turns out that your value column is too big to be indexed and you decided to use md5 hashes instead (which is a good solution):

• Character varying index overhead & length limit

Consider storing the md5 hash as uuid, which would be most efficient (smaller, faster storage). You can just cast the result to uuid:

md5(value)::uuid

Details in the last chapter of this answer:

• Convert hex in text representation to decimal number

Related:

• Would index lookup be noticeably faster with char vs varchar when all values are 36 chars
• How to add a PostgreSQL GIN index on a uuid in Postgres 9.6

Your index would look like this:

CREATE INDEX eav_value_special_idx
ON eav_value_text_data (cast(md5(value) AS uuid), attribute);

Note the explicit cast() syntax in the index definition:

• How to create an index on an integer json property in postgres

Your query can still use shorthand syntax:

SELECT count(*)
FROM   eav_value_text_data v 
JOIN   eav_attribute a ON a.id = v.attribute 
WHERE  a.data_type = 11 
AND    a.name = 'id' 
AND    md5(v.value)::uuid = md5('rs145368920')::uuid;