From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Alban Hertroys <alban(at)magproductions(dot)nl> |
Cc: | Jim Nasby <jnasby(at)pervasive(dot)com>, hubert depesz lubaczewski <depesz(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: A slow query - Help please? |
Date: | 2006-06-21 14:45:57 |
Message-ID: | 20060621144557.GH7859@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Jun 21, 2006 at 04:12:08PM +0200, Alban Hertroys wrote:
> Martijn van Oosterhout wrote:
> >ISTM that what would really work well is some kind of "Merge Sort" node
> >that would work by having multiple subnodes which are already sorted
> >and merging them into one sorted list.
>
> Would... So this isn't available yet?
Not AFAIK.
> >It would push the ORDER BY down to the subqueries and then merge the
> >results. If the subqueries can be read efficiently sorted (via an index
> >for example) then you would get very quick output, especially if you
> >have a LIMIT clause.
>
> I just realized that OFFSET kind of complicates the problem.
>
> If PostgreSQL would handle this (for inheritance as well, I hope), it'd
> need to keep track of how many records came from which tables to set the
> offsets in the subqueries appropriately, which of course depends on the
> previous query... Well, I said it complicates things...
OFFSET is not a problem at all. It's just code for "throw away first N
rows". Once you have the above node type, the executor would simply
throw away somed rows, whichever table they came from.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Jasbinder Bali | 2006-06-21 16:03:26 | Re: Dynamic loading of C functions |
Previous Message | Alban Hertroys | 2006-06-21 14:12:08 | Re: A slow query - Help please? |