[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
Дата:
От: Jaime Casanova
Дата:
Сообщение: triggers and inheritance tree
FAQ