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
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
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
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
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:
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