Re: Row estimates for empty tables
От | Pavel Stehule |
---|---|
Тема | Re: Row estimates for empty tables |
Дата | |
Msg-id | CAFj8pRDkw_c1Ybp8XxryA-FAYTCj86ouU8sGsyz+7B+vH5LjDg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Row estimates for empty tables (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Row estimates for empty tables
|
Список | pgsql-hackers |
po 24. 8. 2020 v 21:43 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
ne 23. 8. 2020 v 23:08 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:Pavel Stehule <pavel.stehule@gmail.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.
Regards
Pavel
RegardsPavel
regards, tom lane
В списке pgsql-hackers по дате отправления: