From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: would it be a lot of work, to add optimizations accross unions ? |
Date: | 2009-02-28 13:31:28 |
Message-ID: | 87bpsmsn67.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> writes:
> On 28 Feb 2009, at 11:37, Gregory Stark wrote:
>>
>> I posted a patch to look for an ordered path for members of a union a while
>> back but it still needed a fair amount of work before it was usable.
>>
> I belive limit it self can't be pushed down, but with order by - why not ?
Because my patch wasn't finished? There were still things about the planner I
didn't understand which blocked me from finishing it at the time.
>>> select foo( select foo from bar1 ) a where foo in (x,y,z) order by foo
>>> desc
>>> limit N
>>
>> huh?
> Just a simple example, perhaps oversimplified.
> The thing is, in case like that - planner could merge two queries together.
No, I meant I don't understand what you're trying to do with this query or
what you would propose the planner should do with it. Afaict this isn't a
valid query at all and I don't see two queries to merge in it.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-02-28 14:53:47 | Re: xpath processing brain dead |
Previous Message | Grzegorz Jaskiewicz | 2009-02-28 11:49:07 | Re: would it be a lot of work, to add optimizations accross unions ? |