Hi!
I'm starting to look at this patchset. Not ready to post detail
review, but have a couple of questions.
On Wed, Sep 19, 2018 at 9:24 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I still haven't managed to add pg_upgrade support, but that's my next
> step. I am more or less happy with the substance of the patch in v5,
> and feel that I can now work backwards towards figuring out the best
> way to deal with on-disk compatibility. It shouldn't be too hard --
> most of the effort will involve coming up with a good test suite.
Yes, it shouldn't be too hard, but it seems like we have to keep two
branches of code for different handling of duplicates. Is that true?
+ * In the worst case (when a heap TID is appended) the size of the returned
+ * tuple is the size of the first right tuple plus an additional MAXALIGN()
+ * quantum. This guarantee is important, since callers need to stay under
+ * the 1/3 of a page restriction on tuple size. If this routine is ever
+ * taught to truncate within an attribute/datum, it will need to avoid
+ * returning an enlarged tuple to caller when truncation + TOAST compression
+ * ends up enlarging the final datum.
I didn't get the point of this paragraph. Does it might happen that
first right tuple is under tuple size restriction, but new pivot tuple
is beyond that restriction? If so, would we have an error because of
too long pivot tuple? If not, I think this needs to be explained
better.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company