Re: [PERFORM] Chaotically weird execution plan

2008-09-23 Thread Scott Carey
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

Re: [PERFORM] Chaotically weird execution plan

2008-09-23 Thread Craig Ringer
Tom Lane wrote: Craig Ringer <[EMAIL PROTECTED]> writes: I'd already written: "If you need the test for status = 1, consider a partial index" when I noticed your schema definition: "comments_created_by" btree (created_by) WHERE status = 1 I find it hard to guess why it's having to recheck

Re: [PERFORM] Chaotically weird execution plan

2008-09-23 Thread Tom Lane
Craig Ringer <[EMAIL PROTECTED]> writes: > I'd already written: "If you need the test for status = 1, consider a > partial index" when I noticed your schema definition: >> "comments_created_by" btree (created_by) WHERE status = 1 > I find it hard to guess why it's having to recheck the WHERE clau

Re: [PERFORM] Chaotically weird execution plan

2008-09-23 Thread Tom Lane
Einars <[EMAIL PROTECTED]> writes: > 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: I don't see anything even slightly wrong h

Re: [PERFORM] Chaotically weird execution plan

2008-09-23 Thread Craig Ringer
Einars wrote: > As query plan shows, it got the > correct answer, 15888, very fast: the rest of the 13 seconds it's just > rechecking all the comments for some weird reasons. I'd already written: "If you need the test for status = 1, consider a partial index" when I noticed your schema definition:

[PERFORM] Chaotically weird execution plan

2008-09-23 Thread Einars
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: select count(*) from comments where created_by=80 and status=1; The comments table