From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
Subject: | Re: TOAST condition for column size |
Date: | 2021-01-19 15:40:39 |
Message-ID: | 479998.1611070839@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dilip Kumar <dilipbalaut(at)gmail(dot)com> writes:
> On Tue, 19 Jan 2021 at 6:28 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> Won't it be safe because we don't align individual attrs of type
>> varchar where length is less than equal to 127?
> Yeah right, I just missed that point.
Yeah, the minimum on biggest_size has nothing to do with alignment
decisions. It's just a filter to decide whether it's worth trying
to toast anything.
Having said that, I'm pretty skeptical of this patch: I think its
most likely real-world effect is going to be to waste cycles (and
create TOAST-table bloat) on the way to failing anyway. I do not
think that toasting a 20-byte field down to 18 bytes is likely to be
a productive thing to do in typical situations. The given example
looks like a cherry-picked edge case rather than a useful case to
worry about.
IOW, if I were asked to review whether the current minimum is
well-chosen, I'd be wondering if we should increase it not
decrease it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-01-19 15:45:35 | Re: Use boolean array for nulls parameters |
Previous Message | James Hilliard | 2021-01-19 15:36:49 | Re: [PATCH 1/1] Fix detection of pwritev support for OSX. |