From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Quan Zongliang <quanzongliang(at)yeah(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, quanzl(at)highgo(dot)com |
Subject: | Re: stored short varlena in array |
Date: | 2025-01-19 21:29:14 |
Message-ID: | 2818372.1737322154@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Quan Zongliang <quanzongliang(at)yeah(dot)net> writes:
> Now, the varlena type is stored directly in the array. Did not consider
> short varlena. If it's like fill_val(), using short varlena saves memory
> footprint and disk space.
TBH, I think this is a bad idea and we should reject it. As you have
already discovered, the code footprint of such a change is enormous
(and I have little confidence that you found all the places to fix).
The consequences would be equally dire in extensions, which'd likely
be dealing with ensuing bugs for years to come.
The reason we didn't do this when we originally invented short varlena
headers is that we presumed that array-level compression would remove
most of the benefit. Of course that only happens if the array is big
enough to get the attention of the tuple toaster, which is why your
example with very small arrays shows a benefit. But I'm doubtful that
such use-cases justify the pain we'd endure getting to the point where
this'd work reliably. The percentage savings drops off drastically as
the length of the individual strings grows, so this example with
one-byte strings is very much a best-case scenario.
In short, I'm afraid this ship sailed a long time ago. Perhaps it
was a poor decision but I think we're stuck with it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-01-19 23:47:14 | Re: attndims, typndims still not enforced, but make the value within a sane threshold |
Previous Message | Michail Nikolaev | 2025-01-19 20:55:32 | Re: Issue with markers in isolation tester? Or not? |