postgresql/src/backend/access/common
Robert Haas 3838074f86 Be more aggressive in avoiding tuple conversion.
According to the comments in tupconvert.c, it's necessary to perform
tuple conversion when either table has OIDs, and this was previously
checked by ensuring that the tdtypeid value matched between the tables
in question.  However, that's overly stringent: we have access to
tdhasoid and can test directly whether OIDs are present, which lets us
avoid conversion in cases where the type OIDs are different but the
tuple descriptors are entirely the same (and neither has OIDs).  This
is useful to the partitioning code, which can thereby avoid converting
tuples when inserting into a partition whose columns appear in the
same order as the parent columns, the normal case.  It's possible
for the tuple routing code to avoid some additional overhead in this
case as well, so do that, too.

It's not clear whether it would be OK to skip this when both tables
have OIDs: do callers count on this to build a new tuple (losing the
previous OID) in such instances?  Until we figure it out, leave the
behavior in that case alone.

Amit Langote, reviewed by me.
2017-01-24 21:53:38 -05:00
..
Makefile Add a new DestReceiver for printing tuples without catalog access. 2017-01-24 16:53:56 -05:00
heaptuple.c Update copyright via script for 2017 2017-01-03 13:48:53 -05:00
indextuple.c Update copyright via script for 2017 2017-01-03 13:48:53 -05:00
printsimple.c Add a new DestReceiver for printing tuples without catalog access. 2017-01-24 16:53:56 -05:00
printtup.c Update copyright via script for 2017 2017-01-03 13:48:53 -05:00
reloptions.c Update copyright via script for 2017 2017-01-03 13:48:53 -05:00
scankey.c Update copyright via script for 2017 2017-01-03 13:48:53 -05:00
tupconvert.c Be more aggressive in avoiding tuple conversion. 2017-01-24 21:53:38 -05:00
tupdesc.c Add a SHOW command to the replication command language. 2017-01-24 17:04:12 -05:00