| 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 |