Re: union vs. sort

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: union vs. sort
Date: 2004-04-06 14:33:25
Message-ID: 24240.1081262005@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> I'm surprise with query plan that PostgreSQL planner prepare for
> selects with ORDER BY if all data are from sub-select that is already
> sorted.

This isn't simply a matter of "omitting the sort". Even if the inputs
are sorted, their concatenation (Append result) isn't sorted: "1 2 3 4"
and "1 3 7 9" are sorted, but "1 2 3 4 1 3 7 9" isn't.

To do what you're thinking about, we'd have to build a variant
implementation of Unique that merges two presorted inputs --- and it
wouldn't work for more than two inputs (at least not without a lot of
pain ... Append is a messy special case in many ways, and we'd have to
duplicate most of that cruft to make an N-input version of Unique).
This is possible, without doubt, but I'm not excited about expending
that much time on it. You haven't shown any evidence that this would be
an important optimization in practice.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Seymour 2004-04-06 14:33:34 Re: Solaris initdb fails: shmmax tweak alternative?
Previous Message Andrew Dunstan 2004-04-06 14:23:21 zero knowledge users