| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, postgre <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Row estimates for empty tables |
| Date: | 2020-07-24 14:38:08 |
| Message-ID: | A2D82246-2556-4BBB-8C44-7F729CC02317@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
> On Jul 24, 2020, at 06:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> There's certainly not a lot besides tradition to justify the exact
> numbers used in this case.
Since we already special-case parent tables for partition sets, would a storage parameter that lets you either tell the planner "no, really, zero is reasonable here" or sets a minimum number of rows to plan for be reasonable? I happened to get bit by this tracking down an issue where several tables in a large query had zero rows, and the planner's assumption of a few pages worth caused some sub-optimal plans. The performance hit wasn't huge, but they were being joined to some *very* large tables, and the differences added up.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vasu Madhineni | 2020-07-24 16:38:50 | TDE implementation in postgres which is in docker container |
| Previous Message | Tom Lane | 2020-07-24 13:48:36 | Re: Row estimates for empty tables |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexey Bashtanov | 2020-07-24 14:55:57 | Re: Improve planner cost estimations for alternative subplans |
| Previous Message | Robert Haas | 2020-07-24 14:37:40 | Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks |