| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Another way to fix inherited UPDATE/DELETE |
| Date: | 2019-02-20 05:21:53 |
| Message-ID: | 14617.1550640113@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> We will need to consider how this affects EvalPlanQual which currently
> doesn't have to do anything special for partitioned tables. I solved that
> via tracking the expanded-at-the-bottom child in a separate
> mergeTargetRelation, but that approach has been criticised. May be Tom's
> idea doesn't have the same problem or most likely he will have a far better
> approach to address that.
I did spend a few seconds thinking about that, and my gut says that
this wouldn't change anything interesting for EPQ. But the devil
is in the details as always, so maybe working out the patch would
find problems ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2019-02-20 05:42:41 | RE: Speed up transaction completion faster after many relations are accessed in a transaction |
| Previous Message | Pavan Deolasee | 2019-02-20 05:11:11 | Re: Another way to fix inherited UPDATE/DELETE |