| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Delay locking partitions during query execution |
| Date: | 2019-02-18 23:50:34 |
| Message-ID: | 11836.1550533834@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
[ reposting some questions asked in the wrong thread ]
What I'd like to understand about this patch is how it relates
to Amit L.'s work on making the planner faster for partitioned
UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/).
I think that that might render this moot? Amit's already
getting rid of unnecessary partition locking.
In any case, I'd counsel against putting planner outputs into
RangeTblEntry. Someday we ought to make parse trees read-only
to the planner, as plan trees are to the executor; defining them
to carry planner results kneecaps any such effort before it starts.
Not to mention the unpleasant consequences for the footprint
of this patch.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2019-02-18 23:52:08 | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
| Previous Message | Tsunakawa, Takayuki | 2019-02-18 23:43:42 | RE: Protect syscache from bloating with negative cache entries |