Re: Query Plan - Bitmap Index Scan and Views
От | Rusty Conover |
---|---|
Тема | Re: Query Plan - Bitmap Index Scan and Views |
Дата | |
Msg-id | B641AA20-EF88-4519-83FB-FAF2A0315415@infogears.com обсуждение исходный текст |
Ответ на | Re: Query Plan - Bitmap Index Scan and Views (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Query Plan - Bitmap Index Scan and Views
|
Список | pgsql-performance |
On Aug 4, 2006, at 8:15 PM, Tom Lane wrote:
Rusty Conover <rconover@infogears.com> writes:Is there any inherent benefit of using a the IN operator versusjoining a temporary table? Should they offer near equal performance?It appears bitmap scan's aren't done when matching across a smalltemporary table.I believe the problem you're facing is that existing PG releasesdon'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 temptable happens after forming the full output of the view, whereas youdesperately need it to happen at the bottom of the join stack.CVS tip (8.2-to-be) has some ability to rearrange outer joins, andI'm interested to know whether it's smart enough to fix your problem.But you have not provided enough info to let someone else duplicateyour test case. Would you be willing to download CVS or a recentnightly 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.
В списке pgsql-performance по дате отправления: