| 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: | Whole Thread | Raw Message | 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. |