Re: TOAST condition for column size

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: "Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TOAST condition for column size
Date: 2021-01-20 12:18:35
Message-ID: b788568a8e28c6b863f768902806d8c8@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-01-19 19:32, Amit Kapila wrote:
> On Mon, Jan 18, 2021 at 7:53 PM torikoshia
> Because no benefit is to be expected by compressing it. The size will
> be mostly the same. Also, even if we somehow try to fit this data via
> toast, I think reading speed will be slower because for all such
> columns an extra fetch from toast would be required. Another thing is
> you or others can still face the same problem with 17-byte column
> data. I don't this is the right way to fix it. I don't have many good
> ideas but I think you can try by (a) increasing block size during
> configure, (b) reduce the number of columns, (c) create char columns
> of somewhat bigger size say greater than 24 bytes to accommodate your
> case.
>
> I know none of these are good workarounds but at this moment I can't
> think of better alternatives.

Thanks for your explanation and workarounds!

On 2021-01-20 00:40, Tom Lane wrote:
> 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.

I agree with you, it seems only work when there are many columns with
19 ~ 23 bytes of data and it's not a normal case.
I'm not sure, but a rare exception might be some geographic data.
That's the situation I heard that problem happened.

Regards,

--
Atsushi Torikoshi

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2021-01-20 12:57:47 Re: Added schema level support for publication.
Previous Message Laurenz Albe 2021-01-20 12:02:51 Re: Stronger safeguard for archive recovery not to miss data