| From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Hans-Juergen Schoenig <postgres(at)cybertec(dot)at> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Optimizing "top queries" ... |
| Date: | 2006-12-06 10:55:17 |
| Message-ID: | 4576A195.4010901@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Hans-Juergen Schoenig wrote:
> in fact, the sort step is not necessary here as we could add a node
> which buffers the highest 10 records and replaces them whenever a
> higher value is returned from the underlaying node (in this case seq scan).
> this query is a quite common scenario when it comes to some analysis
> related issues.
> saving the sort step is an especially good idea when the table is very
> large.
That sounds very much like what's known as 'partial sort', which has
been proposed by Oleg and Theodor. AFAIK they had a trivial patch
sometime around version 7.1, without integration into the planer and
optimizer. They were talking about libpsort, but I can't find that
currently. See archives [1] and [2].
Regards
Markus
[1]: http://archives.postgresql.org/pgsql-sql/2002-01/msg00316.php
[2]: http://archives.postgresql.org/pgsql-hackers/2006-09/msg01532.php
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hubert FONGARNAND | 2006-12-06 13:51:34 | Bug in PostGreSQL 8.2 |
| Previous Message | Hans-Juergen Schoenig | 2006-12-06 10:36:52 | Optimizing "top queries" ... |