On Fri, Sep 8, 2017 at 1:38 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>> I also confirmed that the partition-pruning patch set works fine with this
>> patch instead of the patch on that thread with the same functionality,
>> which I will now drop from that patch set. Sorry about the wasted time.
>
> Thanks a lot. Please review the patch in the updated patchset.
In set_append_rel_size(), I don't find the comment too clear (and this
part was taken from Amit's patch, right?). I suggest:
+ /*
+ * Associate the partitioned tables which are descendents of the table
+ * named in the query with the topmost append path (i.e. the one where
+ * rel->reloptkind is RELOPT_BASEREL). This ensures that they get properly
+ * locked at execution time.
+ */
I'm a bit suspicious about the fact that there are now executor
changes related to the PlanRowMarks. If the rowmark's prti is now the
intermediate parent's RT index rather than the top-parent's RT index,
it'd seem like that'd matter somehow. Maybe it doesn't, because the
code that cares about prti seems to only care about whether it's
different from rti. But if that's true everywhere, then why even
change this? I think we might be well off not to tinker with things
that don't need to be changed.
Apart from that concern, now that I understand (from my own failed
attempt and some off-list discussion) why this patch works the way it
does, I think this is in fairly good shape.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers