Re: installcheck failing on psql_crosstab

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: installcheck failing on psql_crosstab
Date: 2016-06-06 15:27:53
Message-ID: 21668.1465226873@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Tom Lane wrote:
>>> Presumably what is happening is that the planner is switching from hash
>>> to sort aggregation.

>> I can't imagine that the server is avoiding hash aggregation on a 1MB
>> work_mem limit for data that's a few dozen of bytes. Is it really doing
>> that?

> Yup:

I looked more closely and found that the reason it's afraid to use hash
aggregation is the amount of transition space potentially needed by
string_agg. That's being estimated as 8kB per group, and with the
(default) estimate of 200 groups, you get about 1.6MB estimated to be
needed.

Also, I confirmed my suspicion that some other regression tests fail
when you reduce work_mem below 1MB. So I'm not really excited
about changing this one.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-06-06 15:28:08 Re: Reviewing freeze map code
Previous Message Alex Ignatov 2016-06-06 15:13:16 Why we don't have checksums on clog files