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