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.
14 matches
Mail list logo
