On Fri, Jun 24, 2016 at 05:25:27PM -0700, Peter Geoghegan wrote: > On Fri, Jun 24, 2016 at 4:29 PM, Andres Freund <and...@anarazel.de> wrote: > > As a motivation, here's a somewhat juicy example of the benefits that > > can be gained (disabled parallelism, results vary too much): > > SELECT l_linestatus, SUM(l_quantity) FROM lineitem GROUP BY 1 ORDER BY 2 > > DESC LIMIT 10 ; > > non-optimized: 9075.835 ms > > optimized: 5194.024 ms > > > > and that's far from doing all the possible work for that query; > > especially the batching is far from optimal. > > That's pretty great. Let me first just say that I think that your > broadly have the right idea here, and that it will likely be a big > area to work on in the years ahead. This may become a big, general > area with many sub-projects, kind of like parallelism. Also, I think > it's very much complementary to parallelism.
Agreed. I did put out a blog entry about this in April that has links to some external projects trying to address this issue: http://momjian.us/main/blogs/pgblog/2016.html#April_1_2016 -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers