Re: hashagg slowdown due to spill changes

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: Re: hashagg slowdown due to spill changes
Date: 2020-06-12 23:06:25
Message-ID: 20200612230625.fezrlwfsgkctk7ok@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Jun 12, 2020 at 03:29:08PM -0700, Jeff Davis wrote:
>On Fri, 2020-06-12 at 14:37 -0700, Andres Freund wrote:
>> I don't see why it's ok to force an additional projection in the very
>> common case of hashaggs over a few rows. So I think we need to
>> rethink
>> 4cad2534da6.
>One possibility is to project only spilled tuples, more similar to
>Melanie's patch from a while ago:
>Which makes sense, but it's also more code.

I agree, we should revert 4cad2534da and only project tuples when we
actually need to spill them. Did any of the WIP patches actually
implement that, or do we need to write that patch from scratch?


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-06-12 23:28:10 Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message David Rowley 2020-06-12 22:58:34 Re: Speedup usages of pg_*toa() functions