Re: A slow query - Help please?

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.

In response to

Browse pgsql-general by date

  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?