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 <dilipbal...@gmail.com> writes:
On Tue, 19 Jan 2021 at 6:28 PM, Amit Kapila <amit.kapil...@gmail.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
