Re: Slow query - index not used - Mailing list pgsql-hackers

From Dennis Bjorklund
Subject Re: Slow query - index not used
Date
Msg-id Pine.LNX.4.44.0401211435120.17713-100000@zigo.dhs.org
Whole thread Raw
In response to Re: Slow query - index not used  (Michael Brusser <michael@synchronicity.com>)
List pgsql-hackers
On Wed, 21 Jan 2004, Michael Brusser wrote:

> So 'rows' values are incorrect.

You can increase the statistics-gathering for that column with ALTER TABLE 
and probably get better estimates.

> Also looking at queries with 'KnowledgeBase'
> and 'OtherParam' - does seq. scan make sense?
> 
> I mean 'rows' has value of about 5000 records from the total of 75000
> records on the table.

It doesn't sound so strange to me. I don't know exactly what limits 
postgresql uses but it probably need to fetch every page in the table to 
find all those 5000 records. If it has to do that then the index scan 
would not help that much (it might even make it slower).

It's easy to test what happens if it do the index scan instead of the seq. 
scan. Just do SET enable_seqscan TO false; before you try the query. Then 
you can compare the times with and without index scan.

Remember, even if it finds a row in the index. it still has to fetch the 
actual row from the table also. So if it needs to fetch all pages from the 
table the total amount of IO is "all of the table" + "the relevant part of 
the index". The if it's faster or not depends on such things as if it's 
already cached in memory. Setting the effective_cache_size correctly lets 
postgresql take into account how much file cache you have which can effect 
the plan.

-- 
/Dennis Björklund



pgsql-hackers by date:

Previous
From: Michael Brusser
Date:
Subject: Re: Slow query - index not used
Next
From: Greg Stark
Date:
Subject: Re: Allow backend to output result sets in XML