Re: [PATCH] Use optimized single-datum tuplesort in ExecSort - Mailing list pgsql-hackers

From Ronan Dunklau
Subject Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Date
Msg-id 15815121.5nURNIQ1oE@aivenronan
Whole thread Raw
In response to Re: [PATCH] Use optimized single-datum tuplesort in ExecSort  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
List pgsql-hackers
> I've now pushed that bug fix so it's fine to remove the change to
> tuplesort.c now.

Thanks, I've rebased the patch, please find attached the v6.

> 
> I also did a round of benchmarking on this patch using the attached
> script. Anyone wanting to run it will need to run make installcheck
> first to create the required tables.

I've run your benchmark, keeping the best of three runs each time.
This is an intel laptop, so as many things are running on it there is a lot of 
noise... 

Both standard and patched run come from a compilation with gcc -O2. No changes 
have been done to the default settings.

Query #    Master    Patched    Variation
1    884    1627    184.05%
2    364    375    103.02%
3    568    783    137.85%
4    296    297    100.34%
5    421    484    114.96%
6    359    408    113.65%
7    237    251    105.91%
8    806    1271    157.69%

Since I didn't reproduce your slowdown at all on the first run, I tried to 
rerun the benchmark several times and for the "dubious cases" (2, 4 and 7), 
the results are too jittery to conclude one way or another in my case.  I 
don't have access to proper hardware, so not sure if that would be useful in 
any way to just run the bench for thousands of xacts instead. I would be 
surprised the check adds that much to the whole execution though.

I attach a graph similar to yours for reference.


-- 
Ronan Dunklau
Attachment

pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Failed transaction statistics to measure the logical replication progress
Next
From: Michael Paquier
Date:
Subject: Re: Introduce pg_receivewal gzip compression tests