From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | boraldomaster <boraldomaster(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Re: Index scan and bitmap index scan - hard to understand how planner chooses |
Date: | 2013-06-24 15:15:16 |
Message-ID: | CAMkU=1y3STe7eJ19GPVQvytKJvmRGy-dm9oCkfGUbuqwbsHNzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Jun 24, 2013 at 5:42 AM, boraldomaster <boraldomaster(at)gmail(dot)com>wrote:
> This seems to be fixed in 9.2.
>
Which version were you originally seeing it in? I still see that behavior
(or something close to it) in 9.4dev.
It stabilizes after doing a "vacuum analyze" (not just "analyze"), but that
is because it then switches to Index Only Scan.
I haven't pinned it down exactly, but it seems that there are two issues.
One is that there are two estimates of the row returned, one for the whole
query (which is visible in EXPLAIN, and is spot on) and one for the index
patch, which is very wrong for 0000% case (the estimate was 1 row rather
than 100, visible only in the debugger or with special logging code added).
The other is that the correlation between index/column order and table
order is thought to be 0 when it is really 1.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Stuart Ford | 2013-06-24 15:25:44 | Re: pg_largeobject.sql script not run after upgrade |
Previous Message | Jan Wieck | 2013-06-24 15:03:02 | Re: .pgpass being ignored |