Re: failures with tuplesort and ordered set aggregates (due to 5cefbf5a6c44) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: failures with tuplesort and ordered set aggregates (due to 5cefbf5a6c44)
Date
Msg-id CAM3SWZSm4GyfjBN1VmzzbtPXK7N53LVEKprJwkW8LBc=UkAMHg@mail.gmail.com
Whole thread Raw
In response to failures with tuplesort and ordered set aggregates (due to 5cefbf5a6c44)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: failures with tuplesort and ordered set aggregates (due to 5cefbf5a6c44)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Feb 20, 2015 at 11:58 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> This seems to happen because ordered_set_startup() calls
> tuplesort_begin_datum() when (use_tuples == true), which only sets
> 'onlyKey' and leaves (sortKeys == NULL). So 'mergeruns' fails because it
> does not expect that.

Oops. You're right. Attached patch fixes the issue, by making
tuplesort_begin_datum() consistent with other comparable routines for
other tuple cases. I think it makes sense to have the 'sortKeys' field
always set, and the 'onlyKey' field also set when that additional
optimization makes sense. That was what I understood the API to be, so
arguably this is a pre-existing issue with tuplesort_begin_datum().

Thanks for the report!
--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Re: Abbreviated keys for Datum tuplesort
Next
From: Eric Grinstein
Date:
Subject: Idea: GSoC - Query Rewrite with Materialized Views