Re: Improving planner variable handling - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Improving planner variable handling
Date
Msg-id 87y77dvkr9.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Improving planner variable handling  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> I wonder if this would help to clean up the equivalence class hacks in 
>> Greg's ordered append patch?
>
> Pretty hard to say at this early stage, 

I've started to have some doubts myself about stuffing all these vars into the
same equivalence class. My concern here is actually performance. I'm concerned
that if you use a partitioned table within a larger query once we've generated
the paths for the partitioned table we don't want to then carry that baggage
of hundreds or possibly thousands of variables for planning the whole rest of
the query above that rel. They'll never be relevant again after that.

The more these ideas start fitting together in my head the more I think Tom's
original instinct would perform better. I was concerned that pulling up and
pushing down pathkey lists sounded like a lot of extra work. But at least you
would only have to pay that for that one level, not carry it along and pay for
it for the rest of the planning.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_terminate_backend() issues
Next
From: Gaetano Mendola
Date:
Subject: /etc/init.d/postgresql status error