From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Christophe Pettus <xof(at)thebuild(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: Row estimates for empty tables |
Date: | 2020-08-25 07:57:25 |
Message-ID: | CAFj8pRC9DXV2QV_dzXDoykDx8LdyRbPghH3bF+LC+pPsxsPz1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
út 25. 8. 2020 v 9:32 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:
>
>
> po 24. 8. 2020 v 21:43 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> napsal:
>
>>
>>
>> ne 23. 8. 2020 v 23:08 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>>
>>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>> > I am sending a patch that is years used in GoodData.
>>>
>>> I'm quite unexcited about that. I'd be the first to agree that the
>>> ten-pages estimate is a hack, but it's not an improvement to ask users
>>> to think of a better value ... especially not as a one-size-fits-
>>> all-relations GUC setting.
>>>
>>
>> This patch is just a workaround that works well 10 years (but for one
>> special use case) - nothing more. Without this patch that application
>> cannot work ever.
>>
>>
>>> I did have an idea that I think is better than my previous one:
>>> rather than lying about the value of relpages, let's represent the
>>> case where we don't know the tuple density by setting reltuples = -1
>>> initially. This leads to a patch that's a good bit more invasive than
>>> the quick-hack solution, but I think it's a lot cleaner on the whole.
>>>
>>
>>> A possible objection is that this changes the FDW API slightly, as
>>> GetForeignRelSize callbacks now need to deal with rel->tuples possibly
>>> being -1. We could avoid an API break if we made plancat.c clamp
>>> that value to zero; but then FDWs still couldn't tell the difference
>>> between the "empty" and "never analyzed" cases, and I think this is
>>> just as much of an issue for them as for the core code.
>>>
>>
>>> I'll add this to the upcoming CF.
>>>
>>
>> I'll check it
>>
>
> I think it can work. It is a good enough solution for people who need a
> different behaviour with minimal impact on people who don't need a change.
>
all tests passed
I'll mark this patch as ready for commit
Regards
Pavel
> Regards
>
> Pavel
>
>
>>
>> Regards
>>
>> Pavel
>>
>>>
>>> regards, tom lane
>>>
>>>
From | Date | Subject | |
---|---|---|---|
Next Message | Dirk Lattermann | 2020-08-25 09:12:35 | Trigger transaction isolation |
Previous Message | Pavel Stehule | 2020-08-25 07:32:42 | Re: Row estimates for empty tables |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2020-08-25 08:06:09 | Re: extension patch of CREATE OR REPLACE TRIGGER |
Previous Message | Pavel Stehule | 2020-08-25 07:32:42 | Re: Row estimates for empty tables |