No obvious perf regression is expected because PG will follow original
qsort code path when mksort is disabled. For the case, the only extra
cost is the check in tuplesort_sort_memtuples() to enter mksort code path.
It's also proved by the experiment today:
Mksort disabled:
2949.287 ms
2955.258 m
On 23/05/2024 15:39, Wang Yao wrote:
No obvious perf regression is expected because PG will follow original
qsort code path when mksort is disabled. For the case, the only extra
cost is the check in tuplesort_sort_memtuples() to enter mksort code path.
And what about the case the mksort is enab
6 PM Wang Yao wrote:
>
>
>
> 获取Outlook for Android
>
> From: Heikki Linnakangas
> Sent: Thursday, May 23, 2024 8:47:29 PM
> To: Wang Yao ; PostgreSQL Hackers
>
> Cc: inte...@outlook.com
> Subject: Re: 回复: An implementation of m
> >
> > 获取Outlook for Android
> > ____________
> > From: Heikki Linnakangas
> > Sent: Thursday, May 23, 2024 8:47:29 PM
> > To: Wang Yao ; PostgreSQL Hackers
> >
> > Cc: inte...@outlook.com
> > Subject: Re: 回复: An imple
ect c1 from t2 order by c6, c5, c4, c3, c2, c1;
> >
> > Results:
> >
> > MKsort:
> > 12374.427 ms
> > 12528.068 ms
> > 12554.718 ms
> >
> > qsort:
> > 12251.422 ms
> > 12279.938 ms
> > 12280.254 ms
> >
> > MKsort is a
hi Tomas,
So many thanks for your kind response and detailed report. I am working
on locating issues based on your report/script and optimizing code, and
will update later.
Could you please also send me the script to generate report pdf
from the test results (explain*.log)? I can try to make one
On 6/14/24 13:20, Yao Wang wrote:
> hi Tomas,
>
> So many thanks for your kind response and detailed report. I am working
> on locating issues based on your report/script and optimizing code, and
> will update later.
>
> Could you please also send me the script to generate report pdf
> from th
On Fri, Jun 14, 2024 at 6:20 PM Yao Wang wrote:
>
> hi Tomas,
>
> So many thanks for your kind response and detailed report. I am working
> on locating issues based on your report/script and optimizing code, and
> will update later.
Hi,
This is an interesting proof-of-concept!
Given the above, I
On 04/07/2024 3:45 pm, Yao Wang wrote:
Generally, the benefit of mksort is mainly from duplicated values and sort
keys: the more duplicated values and sort keys are, the bigger benefit it
gets.
...
1. Use distinct stats info of table to enable mksort
It's kind of heuristics: in optimizer, ch
On 7/4/24 14:45, Yao Wang wrote:
> Hi John,
>
> Thanks for your kind message. I talked to Heikki before getting Tomas's
> response, and he said "no promise but I will take a look". That's why I
> added his email. I have updated the CF entry and added Tomas as reviewer.
>
> Hi Tomas,
>
> Again
On 7/7/24 08:32, Konstantin Knizhnik wrote:
>
> On 04/07/2024 3:45 pm, Yao Wang wrote:
>> Generally, the benefit of mksort is mainly from duplicated values and
>> sort
>> keys: the more duplicated values and sort keys are, the bigger benefit it
>> gets.
> ...
>> 1. Use distinct stats info of ta
BTW I forgot to report that I intended to test this on 32-bit ARM too,
because that sometimes triggers "funny" behavior, but the build fails
like this:
In file included from tuplesort.c:630:
mk_qsort_tuple.c: In function ‘mkqs_compare_datum_by_shortcut’:
mk_qsort_tuple.c:167:23: warning: implicit
On Sun, Jul 7, 2024 at 2:32 AM Konstantin Knizhnik wrote:
> If mksort really provides advantage only when there are a lot of
> duplicates (for prefix keys?) and of small fraction of duplicates there
> is even some (small) regression
> then IMHO taking in account in planner information about estima
On Fri, Jul 26, 2024 at 6:18 PM Yao Wang wrote:
> 2. Should we update optimizer to take in account statistic
> (pg_statistic->stadistinct) and choose mksort/qsort accordingly?
> According to the result, the choosing mechanism in optimizer
> almost eliminated all regressions. Please note that eve
14 matches
Mail list logo
