On Wed, Jun 8, 2016 at 8:21 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Michael Paquier writes:
>> > On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier
>> > wrote:
>> >> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
>> >> wrote:
>> >>> Hmm, so we could solve the complaint by adding an ANALYZ
Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier
> > wrote:
> >> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
> >> wrote:
> >>> Hmm, so we could solve the complaint by adding an ANALYZE. I'm open to
> >>> that; other opinions?
>
> >> We could ju
Michael Paquier writes:
> On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier
> wrote:
>> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
>> wrote:
>>> Hmm, so we could solve the complaint by adding an ANALYZE. I'm open to
>>> that; other opinions?
>> We could just enforce work_mem to 64kB and th
On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier
wrote:
> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera writes:
>>
>>> > 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 byte
On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>
>> > 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:
>
> Aha. Thanks for
I wrote:
> Alvaro Herrera 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
Tom Lane wrote:
> Alvaro Herrera writes:
> > 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:
Aha. Thanks for testing.
> Now that you mention it, this does seem a bit odd, alth
Alvaro Herrera 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?
Y
Tom Lane wrote:
> Alvaro Herrera writes:
> > Michael Paquier wrote:
> >> I know that we guarantee that make installcheck may not work on many
> >> target servers as a lot of tests are very GUC-sensitive, but this
> >> looks a bit oversensitive to me, especially knowing that it is the
> >> only dif
Alvaro Herrera writes:
> Michael Paquier wrote:
>> I know that we guarantee that make installcheck may not work on many
>> target servers as a lot of tests are very GUC-sensitive, but this
>> looks a bit oversensitive to me, especially knowing that it is the
>> only diff generated by the whole tes
Michael Paquier wrote:
> I know that we guarantee that make installcheck may not work on many
> target servers as a lot of tests are very GUC-sensitive, but this
> looks a bit oversensitive to me, especially knowing that it is the
> only diff generated by the whole test suite.
> Don't you think th
Hi all,
With a low value of work_mem, like 1MB, I am noticing that the new
psql_crosstab is generating a couple of diffs with installcheck
(tested only on OSX 10.11):
***
*** 127,134
\crosstabview v h i
v | h0 | h1 | h2 | h4 | #null#
+++++-
12 matches
Mail list logo
