Re: Parallel Seq Scan
От | Robert Haas |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | CA+TgmoaM+Vr_P6nkj+hRb8VxRDUsL6Ch-aXE5q4Z3ZNJtxAJdg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-hackers |
On Sat, Dec 6, 2014 at 12:13 AM, David Rowley <dgrowleyml@gmail.com> wrote: > It's bare-bones core support for allowing aggregate states to be merged > together with another aggregate state. I would imagine that if a query such > as: > > SELECT MAX(value) FROM bigtable; > > was run, then a series of parallel workers could go off and each find the > max value from their portion of the table and then perhaps some other node > type would then take all the intermediate results from the workers, once > they're finished, and join all of the aggregate states into one and return > that. Naturally, you'd need to check that all aggregates used in the > targetlist had a merge function first. I think this is great infrastructure and could also be useful for pushing down aggregates in cases involving foreign data wrappers. But I suggest we discuss it on a separate thread because it's not related to parallel seq scan per se. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: