Optimizing "top queries" ...
От | Hans-Juergen Schoenig |
---|---|
Тема | Optimizing "top queries" ... |
Дата | |
Msg-id | ABFD750F-8FD7-468D-AC56-4DB1CEF92A61@cybertec.at обсуждение исходный текст |
Ответы |
Re: Optimizing "top queries" ...
|
Список | 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
В списке pgsql-hackers по дате отправления: