On Mon, Jul 7, 2014 at 7:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> The testing I did showed about a 5% overhead on REINDEX INDEX
> pgbench_accounts_pkey from one extra tuple copy (cf.
> 9f03ca915196dfc871804a1f8aad26207f601fd6). Of course that could vary
> by circumstance for a variety of reasons.
Be careful of the check for pre-sorted input within qsort() giving an
overly optimistic picture of things, thereby exaggerating the
proportion of time spent copying if taken as generally representative.
>> OTOH, I'd be concerned about the cost of main
>> memory accesses for pass-by-reference types during parallel tuple
>> sorts in particular. The same concern applies to cases where the tuple
>> proper must be accessed, although presumably that occurs less
>> frequently.
>
> I do think that's a problem with our sort implementation, but it's not
> clear to me whether it's *more* of a problem for parallel sort than it
> is for single-backend sort.
If you'll forgive me for going on about my patch on this thread, I
think the pgbench "-c 4" and "-c 1" cases that I tested suggest it is
a particular problem for parallel sorts, as there is a much bigger
both absolute and proportional difference in transaction throughput
between those two with the patch applied. It seems reasonable to
suppose the difference would be larger still if we were considering a
single parallel sort, as opposed to multiple independent sorts (of the
same data) that happen to occur in parallel.
--
Peter Geoghegan