On Wed, May 13, 2015 at 2:44 PM, Peter Geoghegan wrote:
> On Wed, May 13, 2015 at 11:40 AM, Robert Haas wrote:
>> Committed. Thanks for the patch and your patience.
>
> This comment was not updated:
>
> /*
> * The sortKeys variable is used by every case other than the datum and
> * hash index
On Wed, May 13, 2015 at 11:40 AM, Robert Haas wrote:
> Committed. Thanks for the patch and your patience.
This comment was not updated:
/*
* The sortKeys variable is used by every case other than the datum and
* hash index cases; it is set by tuplesort_begin_xxx. tupDesc is only
* used by t
On Fri, Jan 23, 2015 at 4:13 PM, Andrew Gierth
wrote:
> [pruning the Cc: list and starting a new thread]
>
> Here's the cleaned-up version of the patch to allow abbreviated keys
> when sorting a single Datum. This also removes comments that suggest
> that the caller of tuplesort_begin_datum should
On Fri, Apr 3, 2015 at 1:17 PM, Stephen Frost wrote:
>> but even I'm not willing to
>> expend the amount of ink and emotional energy you have on whether a
>> variable that holds +1, 0, or -1 ought to be declared as "int" or
>> "int32". Does it matter? Yeah. Is it worth this much argument? No.
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm about as much
> of a stickler for the details as you will find on this mailing list,
> or possibly, in the observable universe,
This made me laugh. :)
> but even I'm not willing to
> expend the amount of ink and emotional energy you have on wheth
On Fri, Apr 3, 2015 at 1:07 PM, Robert Haas wrote:
> I'm about as much
> of a stickler for the details as you will find on this mailing list,
> or possibly, in the observable universe, but even I'm not willing to
> expend the amount of ink and emotional energy you have on whether a
> variable that
On Thu, Apr 2, 2015 at 7:02 PM, Peter Geoghegan wrote:
> On Thu, Apr 2, 2015 at 11:21 PM, Robert Haas wrote:
>>> The changes that Andrew
>>> took issue with are utterly insignificant.
>>
>> Great. Then you will be utterly indifferent to which version gets committed.
>
> *shrug*
>
> You were the
On Thu, Apr 2, 2015 at 11:21 PM, Robert Haas wrote:
> On Thu, Apr 2, 2015 at 5:34 PM, Peter Geoghegan wrote:
>> I think it's explained by the pre-check for sorted input making the
>> number of comparisons exactly n -1. As I pointed out to Tomas, if you
>> put a single, solitary unsorted element a
On Thu, Apr 2, 2015 at 11:21 PM, Robert Haas wrote:
>> The changes that Andrew
>> took issue with are utterly insignificant.
>
> Great. Then you will be utterly indifferent to which version gets committed.
*shrug*
You were the one that taught me to be bureaucratically minded about
keeping code
On Thu, Apr 2, 2015 at 5:34 PM, Peter Geoghegan wrote:
> I think it's explained by the pre-check for sorted input making the
> number of comparisons exactly n -1. As I pointed out to Tomas, if you
> put a single, solitary unsorted element at the end, the abbreviated
> version is then 8x faster (ma
On Thu, Apr 2, 2015 at 8:17 PM, Robert Haas wrote:
> On Fri, Feb 20, 2015 at 3:57 PM, Tomas Vondra
> wrote:
>> I've spent a fair amount of testing this today, and when using the
>> simple percentile_disc example mentioned above, I see this pattern:
>>
>> master
On Fri, Feb 20, 2015 at 3:57 PM, Tomas Vondra
wrote:
> I've spent a fair amount of testing this today, and when using the
> simple percentile_disc example mentioned above, I see this pattern:
>
> master patched speedup
>-
On Fri, Mar 13, 2015 at 7:51 PM, Andrew Gierth
wrote:
> Since ApplySortComparator returns int, and "compare" is used to store
> the return value of comparetup_datum which is also declared int, this
> seems inappropriate even as a "stylistic tweak".
Consistency matters. That change, and the other
> "Peter" == Peter Geoghegan writes:
Peter> I attach a slightly tweaked version of Andrew's original.
You changed this:
static int
comparetup_datum(const SortTuple *a, const SortTuple *b, Tuplesortstate *state)
{
-int compare;
+int32 compare;
compare = Apply
On Sun, Jan 25, 2015 at 3:15 AM, Andrew Gierth
wrote:
> Robert> I think this is a good idea. Do you have a test case that
> Robert> shows the benefit?
>
> The best test case for datum sort performance is to use percentile_disc,
> since that has almost no overhead beyond performing the actual so
On 25.1.2015 12:15, Andrew Gierth wrote:
>
> So given some suitable test data, such as
>
> create table stuff as select random()::text as randtext
> from generate_series(1,100); -- or however many rows
>
> you can do
>
> select percentile_disc(0) within group (order by randtext) from stuf
> "Robert" == Robert Haas writes:
>> Here's the cleaned-up version of the patch to allow abbreviated keys
>> when sorting a single Datum. This also removes comments that suggest
>> that the caller of tuplesort_begin_datum should ever have to care
>> about the abbreviated key optimization.
On Sat, Jan 24, 2015 at 6:19 PM, Robert Haas wrote:
> I think this is a good idea. Do you have a test case that shows the benefit?
I agree. It seems likely that this will show a similar benefit to
other cases already tested, but I'd like to see a test case too.
--
Peter Geoghegan
--
Sent vi
On Fri, Jan 23, 2015 at 4:13 PM, Andrew Gierth
wrote:
> [pruning the Cc: list and starting a new thread]
>
> Here's the cleaned-up version of the patch to allow abbreviated keys
> when sorting a single Datum. This also removes comments that suggest
> that the caller of tuplesort_begin_datum should
19 matches
Mail list logo
