Optimizing "top queries" ...

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Optimizing "top queries" ...
Date: 2006-12-06 10:36:52
Message-ID: ABFD750F-8FD7-468D-AC56-4DB1CEF92A61@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

hello everybody ...

i was thinking about introducing a new executor node to optimize the
following scenario a little:

test=# explain select * from t_lock order by id limit 10;
QUERY PLAN
------------------------------------------------------------------------
--
Limit (cost=14821.84..14821.87 rows=10 width=4)
-> Sort (cost=14821.84..15149.52 rows=131072 width=4)
Sort Key: id
-> Seq Scan on t_lock (cost=0.00..1888.72 rows=131072
width=4)
(4 rows)

test=# \d t_lock
Table "public.t_lock"
Column | Type | Modifiers
--------+---------+-----------
id | integer |

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.

we could use the new node when the desired subset of data is expected
to fit into work_mem.

how about it?

best regards,

hans-jürgen schönig

--
Cybertec Geschwinde & Schönig GmbH
Sch?ngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Schiltknecht 2006-12-06 10:55:17 Re: Optimizing "top queries" ...
Previous Message Andrew Dunstan 2006-12-06 06:57:17 Re: psql possible TODO