Re: Improving on MAX_CONVERSION_GROWTH

2019-10-03 Thread Andres Freund
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.1569356...@sss.pgh.pa.us>), or something close to it. > > Andres' proposal would perhaps be an improvement on that, but I don't > > think i

Re: Improving on MAX_CONVERSION_GROWTH

2019-10-03 Thread Tom Lane
I wrote: > In the meantime, I still think we should commit what I proposed in the > other thread (<974.1569356...@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 > b

Re: Improving on MAX_CONVERSION_GROWTH

2019-09-27 Thread Tom Lane
Robert Haas writes: > On Fri, Sep 27, 2019 at 11:40 AM Andres Freund wrote: >> Note that one of the additional reasons for the 1GB limit is that it >> protects against int overflows. I'm somewhat unconvinced that that's a >> sensible approach, but ... > It's not crazy. People using 'int' rather

Re: Improving on MAX_CONVERSION_GROWTH

2019-09-27 Thread Robert Haas
On Fri, Sep 27, 2019 at 11:40 AM Andres Freund wrote: > Note that one of the additional reasons for the 1GB limit is that it > protects against int overflows. I'm somewhat unconvinced that that's a > sensible approach, but ... It's not crazy. People using 'int' rather casually just as they use 'p

Re: Improving on MAX_CONVERSION_GROWTH

2019-09-27 Thread Andres Freund
Hi, On 2019-09-27 10:53:48 -0400, Robert Haas wrote: > A lot of that is because they hit the 1GB allocation limit, and I > wonder whether we shouldn't be trying harder to avoid imposing that > limit in multiple places. > It's reasonable - and necessary - to impose > a limit on the size of an indi

Re: Improving on MAX_CONVERSION_GROWTH

2019-09-27 Thread Robert Haas
On Tue, Sep 24, 2019 at 5:15 PM Tom Lane wrote: > In any case, it seems likely that we could end up with a > multiplier of 1, 2, or 3 rather than 4 in just about every > case of practical interest. That sure seems like a win > when converting long strings. +1. From what I've seen, I'd say this i

Improving on MAX_CONVERSION_GROWTH

2019-09-24 Thread Tom Lane
Thinking about the nearby thread[1] about overrunning MaxAllocSize during encoding conversion, it struck me that another thing we could usefully do to improve that situation is to be smarter about what's the growth factor --- the existing one-size-fits-all choice of MAX_CONVERSION_GROWTH = 4 is lea