On Wed, Oct 10, 2012 at 09:24:32PM -0400, Tom Lane wrote:
> I'd not been thinking of that change as something we'd risk
> back-patching, but maybe we should consider putting it into 9.2. It
> seems like the index-only scan support has put a new level of premium on
> the quality of the planner's ro
Greg Sabino Mullane writes:
> -> Bitmap Heap Scan on foobar o (C=30389..835271 R=8980 W=8)
> (AT=0.06..0.07 R=1 L=1)
>Recheck Cond: (((id) >= (m.id)) AND ((id) <= ((m.id) ||
> '.99')))
>Filter: (((status) <> ALL ('{panda,penguin}'[])) \
> AND ((id)
Found a good demonstration of the problem. Here's explain analyze of a
query on 9.2 with enable_indexonlyscan = off; This produces the exact same
plan as 8.3. The tables in question have been analyzed. Changing
random_page_cost has no effect. The main foobar table has 17M rows.
I did multiple r
Greg Sabino Mullane writes:
> Found a good demonstration of the problem. Here's explain analyze of a
> query on 9.2 with enable_indexonlyscan = off; This produces the exact same
> plan as 8.3. The tables in question have been analyzed. Changing
> random_page_cost has no effect. The main foobar
On Wed, Oct 10, 2012 at 01:31:29PM -0400, Tom Lane wrote:
> The above doesn't seem like a regression to me. You told it not to use
> a seqscan, and it didn't. (The reason it now considers the index is
> that an index-only scan is possible; before 9.2 there was no reason to
> consider an indexscan
Greg Sabino Mullane writes:
> We are seeing a performance regression when moving to 9.2. There is a
> complex query that is doing a self-join, but long story short, it
> is choosing to use a multi-column index when it really ought not to be.
> I was not able to develop a standalone test case wit
