From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Vitaliy Litovskiy <vitaliy(dot)litovskiy(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Cc: | Oleg Bartunov <obartunov(at)postgrespro(dot)ru> |
Subject: | Re: Distinct performance dropped by multiple times in v16 |
Date: | 2024-06-12 12:10:47 |
Message-ID: | c82e79fb-037f-4b73-a8a5-171660c767f4@postgrespro.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 6/10/24 13:59, Vitaliy Litovskiy wrote:
> 2.2 unnest is removed. it is not really needed for this particular data
> but this query is autogenerated and unnest makes sense for other data
>
> 2.3 "order by token" is uncommented, this is my current way of fixing
> the problem I would really appreciate some feedback if that is expected
> behaviour and if there are better solutions
After second thought I found that the key issue here is too cheap cycles
other unnest() routine. unnest procost is 1 as any other routines but it
looks a bit more costly than it is.
Also, you can tune cpu_operator_cost a bit. Right now it is set to
0.0025 by default. Increasing it to 0.005:
SET cpu_operator_cost = 0.005;
resolves your issue.
I guess, the value of cpu_operator_cost usually not a problem, because
table pages costs much more. But here function calls are the main source
of load and because of that need to be estimated more precisely.
I hope this will be helpful for you.
--
regards,
Andrei Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2024-06-12 12:25:43 | Re: Need help on configuration SMTP |
Previous Message | Muhammad Ikram | 2024-06-12 12:01:29 | Re: Need help on configuration SMTP |