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