Horton

Re: Improving on MAX_CONVERSION_GROWTH

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-10-03T16:12:40Z
Lists: pgsql-hackers 
I wrote:
> In the meantime, I still think we should commit what I proposed in the
> other thread (<974.1569356381@sss.pgh.pa.us>), or something close to it.
> Andres' proposal would perhaps be an improvement on that, but I don't
> think it'll be ready anytime soon; and for sure we wouldn't risk
> back-patching it, while I think we could back-patch what I suggested.
> In any case, that patch is small enough that dropping it would be no big
> loss if a better solution comes along.

Not having heard any objections, I'll proceed with that.  Andres is
welcome to work on replacing it with his more-complicated idea...

> Also, as far as the immediate subject of this thread is concerned,
> I'm inclined to get rid of MAX_CONVERSION_GROWTH in favor of using
> the target encoding's max char length.

I realized after re-reading the comment for MAX_CONVERSION_GROWTH that
this thread is based on a false premise, namely that encoding conversions
always produce one "character" out per "character" in.  In the presence of
combining characters and suchlike, that premise fails, and it becomes
quite unclear just what the max growth ratio actually is.  So I'm going
to leave that alone for now.  Maybe this point is an argument for pushing
forward with Andres' approach, but I'm still dubious about the overall
cost/benefit ratio of that concept.

			regards, tom lane

Commits

  1. Avoid unnecessary out-of-memory errors during encoding conversion.

  2. Allow repalloc() to give back space when a large chunk is downsized.