Einars, you may be able to force a query plan similar to the first one, on the second data set, if you decrease the random page cost or disable bitmap scans. If a regular index scan is faster than the bitmap scan with the same query returning the same results, there may be some benefit that can be gained with tuning further. But it isn't likely and will depend on how likely the pages are to be in RAM versus disk. If this is a big problem for you, it may be worth trying however.
On Tue, Sep 23, 2008 at 7:58 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Einars <einars@xxxxxxxxx> writes:I don't see anything even slightly wrong here. Your first example pulls
> When displaying information about information about an user in our
> site, I noticed an unreasonable slowdown. The culprit turned out to be
> a trivial select, which determines the number of comments left by an
> user:
15888 rows from the table in 13134 ms. Your second example pulls 3
rows from the table in 0.121 ms --- which I rather imagine is because
those three rows are already in cache; it would take a lot longer if it
actually had to go to disk several times.
The planner's rowcount estimates are on target and it appears to be
choosing appropriate plans in each case. It just takes longer to
process 5000 times as many rows ...
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
