From: | Jon Zeppieri <zeppieri(at)gmail(dot)com> |
---|---|
To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Help with row estimate problem |
Date: | 2024-07-30 17:22:11 |
Message-ID: | CAKfDxxwjF2gMXS7koK1Zy87sC+NDcL89UeZbS-1QfckZjPX7Kw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Jul 30, 2024 at 11:34 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>
> Thanks for report. I see such cases frequently enough and the key
> problem here is data skew, as you already mentioned. Extended statistics
> doesn't help here. Also, because we can't estimate specific values
> coming from the outer NestLoop - we can't involve MCV to estimate
> selectivity of the population. That's the reason why the optimiser uses
> ndistinct value.
> What you can do? I see only one option - split the table to some
> partitions where data will be distributed more or less uniformly. And
> invent a criteria for pruning unnecessary partitions.
> Of course, you can also try pg_hint_plan and force planner to use
> MergeJoin or HashJoin in that suspicious case.
Thanks for the reply, Andrei, and for the advice about partitioning.
- Jon
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-07-30 19:46:46 | Re: proposal: schema variables |
Previous Message | Andrei Lepikhov | 2024-07-30 15:34:20 | Re: Help with row estimate problem |