| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: open/lseek overhead with many partitions (including with "faster partitioning pruning") |
| Date: | 2018-04-04 00:26:58 |
| Message-ID: | 5876f90f-0343-76fa-ac26-e5ffba7d04f6@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Justin.
On 2018/04/04 4:46, Justin Pryzby wrote:
> TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file
> backing every table being queried, even for those partitions eventually
> "excluded".
That's expected. The faster pruning patch doesn't change the behavior
with respect to when the partitions' files are open()'d, which at this
point is still *before* the pruning occurs. It just switches the method
of pruning to a faster one, whereby instead of pruning each partition
one-by-one using constraint exclusion, we only look at the parent's
partition descriptor to exclude partitions that don't satisfy the query.
Thanks,
Amit
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-04-04 00:27:25 | Re: open/lseek overhead with many partitions (including with "faster partitioning pruning") |
| Previous Message | Thomas Munro | 2018-04-03 23:59:27 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |