| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Cc: | 'Mike Palmiotto' <mike(dot)palmiotto(at)crunchydata(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [RFC] [PATCH] Flexible "partition pruning" hook |
| Date: | 2019-02-26 07:37:02 |
| Message-ID: | 20190226073702.GJ27822@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 26, 2019 at 06:55:30AM +0000, Tsunakawa, Takayuki wrote:
> What concrete problems would you expect this patch to solve? What
> kind of extensions do you imagine? I'd like to hear about the
> examples. For example, "PostgreSQL 12 will not be able to filter
> out enough partitions when planning/executing SELECT ... WHERE
> ... statement. But an extension like this can extract just one
> partition early."
Indeed. Hooks should be defined so as their use is as generic and
possible depending on their context, particularly since there is a
planner hook.. It is also important to consider first if the existing
core code can be made better depending on the requirements, removing
the need for a hook at the end.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2019-02-26 07:56:37 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |
| Previous Message | Michael Paquier | 2019-02-26 07:31:01 | Re: Unused parameters & co in code |