[PATCH] Lazy hashaggregate when no aggregation is needed
От
Ants Aasma
Тема
[PATCH] Lazy hashaggregate when no aggregation is needed
Дата
Msg-id
CA+CSw_uE-RCyQd_bXJNe=usrXkq+keFrQrahkc+8ou+Ws4Y=Vw@mail.gmail.com
Список
Дерево обсуждения
[PATCH] Lazy hashaggregate when no aggregation is needed Ants Aasma <ants@cybertec.at>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Jay Levitt <jay.levitt@gmail.com>
Re: [PATCH] Lazy hashaggregate when no aggregation
is needed Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Robert Haas <robertmhaas@gmail.com>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Ants Aasma <ants@cybertec.at>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Robert Haas <robertmhaas@gmail.com>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Robert Haas <robertmhaas@gmail.com>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Robert Haas <robertmhaas@gmail.com>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Ants Aasma <ants@cybertec.at>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Robert Haas <robertmhaas@gmail.com>
Re: [PATCH] Lazy hashaggregate when no aggregation is needed Ants Aasma <ants@cybertec.at>
A user complained on pgsql-performance that SELECT col FROM table GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe to return tuples from hash-aggregate as they are found when no aggregate functions are in use. Attached is a first shot at that. The planner is modified so that when the optimization applies, hash table size check is compared against the limit and start up cost comes from the input. The executor is modified so that when the hash table is not filled yet and the optimization applies, nodes are returned immediately. Can somebody poke holes in this? The patch definitely needs some code cleanup in nodeAgg.c, but otherwise it passes regression tests and seems to work as intended. It also optimizes the SELECT DISTINCT col FROM table LIMIT 2; case, but not SELECT DISTINCT ON (col) col FROM table LIMIT 2 because it is explicitly forced to use sorted aggregation. Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
В списке pgsql-hackers по дате отправления
От: Fujii Masao
Дата: