Horton

Re: Improving on MAX_CONVERSION_GROWTH

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-10-03T16:20:14Z
Lists: pgsql-hackers 
Hi,

On 2019-10-03 12:12:40 -0400, Tom Lane wrote:
> 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...

Yea, what I'm proposing is clearly not backpatchable. So +1


> 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.

I think if it were just for MAX_CONVERSION_GROWTH, I'd be inclined to
agree. But I think it has other advantages, so I'm mildy positivie that
it'll be an overall win...

Greetings,

Andres Freund

Commits

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

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