Re: Query Plan - Bitmap Index Scan and Views

From: Rusty Conover <rconover(at)infogears(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Query Plan - Bitmap Index Scan and Views
Date: 2006-08-05 02:56:54
Message-ID: B641AA20-EF88-4519-83FB-FAF2A0315415@infogears.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On Aug 4, 2006, at 8:15 PM, Tom Lane wrote:

> Rusty Conover <rconover(at)infogears(dot)com> writes:
>> Is there any inherent benefit of using a the IN operator versus
>> joining a temporary table? Should they offer near equal performance?
>> It appears bitmap scan's aren't done when matching across a small
>> temporary table.
>
> I believe the problem you're facing is that existing PG releases
> don't know how to rearrange join order in the face of outer joins,
> and your view is full of outer joins. So the join against the temp
> table happens after forming the full output of the view, whereas you
> desperately need it to happen at the bottom of the join stack.
>
> CVS tip (8.2-to-be) has some ability to rearrange outer joins, and
> I'm interested to know whether it's smart enough to fix your problem.
> But you have not provided enough info to let someone else duplicate
> your test case. Would you be willing to download CVS or a recent
> nightly snapshot and see what it does with your problem?
>
> regards, tom lane

Absolutely, I'll attempt to run the test against the current CVS HEAD.

Do I need to pg_dump and restore from 8.1.4?

What other information would be helpful in the meantime?

Thanks,

Rusty
--
Rusty Conover
InfoGears Inc.
Web: http://www.infogears.com

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-08-05 03:27:08 Re: Query Plan - Bitmap Index Scan and Views
Previous Message Tom Lane 2006-08-05 02:15:18 Re: Query Plan - Bitmap Index Scan and Views