Question: I have newly installed WordPress copy on my live server but on google search it show 

```
"this site might be hacked " 

```

message under my site link. i have applied the search console verification method of uploading html file into root folder but this error is not gone. checked into Security options tab it shows "content injection" spam issue with my site but i have not found any accurate method to solve that issue .

Answer: 
An index is used to (quickly) find "a few" rows in "many rows". It's not a magical silver bullet that makes everything go faster. 

You don't have enough rows in your tables to make an index lookup efficient. And you are getting nearly all of them, not just a small part.

If you look at the plan you will see that the actual data retrieval never takes more then 0.1 ms. (that's a tenth of a **milli**second). The Seq Scan for tables `c` and `d` only takes 0.004ms - no index will speed that up for only 4 rows. 

Doing that through indexes with random I/O for just 20 or 30 rows would definitely be slower. Depending on the number of columns in the tables even the 39 rows of the "biggest" table are probably stored on a single block - which means to read all rows, the database only needs to do a single I/O operation when using a Seq Scan.

The slowest part of the plan is the `HashAggregate` **not** the *reading* of the data, so the choice to not use an index seems correct. 

What kind of hardware is that? 175 milliseconds to aggregate 20 rows seems extremely slow - as is the planning time of 210ms. For such a simple statement, the planning time should be more like 1ms.
There is ony one criteria on table A: `WHERE a.owner_id NOT IN (1, 3, 100, 41)`. To me that sounds like "select all records except a few". It would be a lot of work to read all records via an index and still end up up with most of them. It's way faster to simply read the table and dismiss some few records on-the-fly.

Then with those many, many A records, we may match many, many B, C, and D records. Again, we'd better don't read indexes plus most of the table data, but simply put the data in buckets (hash join). That seems fastest.

So that the the optimizer chooses not to use indexes for your query seems like a good idea. It proves that it's doing a good job :-)

The only way I see to speed this up with indexes would be covering indexes, i.e. indexes containing all desired columns:

* a(owner\_id, id, created\_date, col2)
* b(fk\_a\_id, id, col2)
* c(fk\_a\_id, id, col2)
* d(fk\_c\_id)

Then we wouldn't have to read the indexes plus the tables, but the indexes alone.

BTW: As you don't select anything from D, you either want to check for existence, then you should use `EXISTS` or `IN` instead of a join for readability in my opinion. Or you don't; then you can dismiss it completely from your query.