Re: Row estimates for empty tables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Row estimates for empty tables
Date
Msg-id CAFj8pRAH+WzDsGeNu9noO+fNX5Q8GC5Xw8JtNfAE2bXAmqfipw@mail.gmail.com
Whole thread Raw
In response to Re: Row estimates for empty tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Row estimates for empty tables
List pgsql-hackers


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

Regards

Pavel

                        regards, tom lane

pgsql-hackers by date:

Previous
From: "Andrey M. Borodin"
Date:
Subject: Re: recovering from "found xmin ... from before relfrozenxid ..."
Next
From: Andres Freund
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans