Laurenz Albe writes:
> On Fri, 2023-09-29 at 18:19 -0400, Bruce Momjian wrote:
>> Where did we end with this? Is a doc patch the solution?
> I don't think this went anywhere, and a doc patch is not the solution.
> Tom has argued convincingly that single-byte headers are an effect of the
>
On Fri, 2023-09-29 at 18:19 -0400, Bruce Momjian wrote:
> On Thu, Jan 12, 2023 at 03:43:57PM +0100, Laurenz Albe wrote:
> > On Tue, 2023-01-10 at 15:53 +, PG Doc comments form wrote:
> > > https://www.postgresql.org/docs/devel/storage-toast.html - This is the
> > > development version.
> > >
On Thu, Jan 12, 2023 at 03:43:57PM +0100, Laurenz Albe wrote:
> On Tue, 2023-01-10 at 15:53 +, PG Doc comments form wrote:
> > https://www.postgresql.org/docs/devel/storage-toast.html - This is the
> > development version.
> >
> > > PLAIN prevents either compression or out-of-line storage;
On Mon, 2023-01-16 at 11:50 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Sun, 2023-01-15 at 16:40 -0500, Tom Lane wrote:
> > > The documentation is correct, what is broken is the code.
>
> > I see. But what is the reason for that anyway? Why not allow short varlena
> > headers if TOAST
Laurenz Albe writes:
> On Sun, 2023-01-15 at 16:40 -0500, Tom Lane wrote:
>> The documentation is correct, what is broken is the code.
> I see. But what is the reason for that anyway? Why not allow short varlena
> headers if TOAST storage is set to PLAIN?
The original motivation for that
On Sun, 2023-01-15 at 16:40 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Tue, 2023-01-10 at 15:53 +, PG Doc comments form wrote:
> > > > PLAIN prevents either compression or out-of-line storage; furthermore it
> > > > disables use of single-byte headers for varlena types. This is the
Hi,
On 2023-01-15 16:49:01 -0800, Andres Freund wrote:
> I don't see how we can fix this mess entirely without tracking the storage
> type a lot more widely. Most importantly in targetlists, as we use the
> targetlists to compute the tupledescs of executor nodes, which then influence
> where we
Hi,
On 2023-01-15 18:41:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-01-15 18:08:21 -0500, Tom Lane wrote:
> >> ri_newTupleSlot has the tupdesc we want, planSlot is a virtual slot
> >> that has the bogus tupdesc, and for some reason heap_form_tuple is
> >> getting called with
Andres Freund writes:
> On 2023-01-15 18:08:21 -0500, Tom Lane wrote:
>> ri_newTupleSlot has the tupdesc we want, planSlot is a virtual slot
>> that has the bogus tupdesc, and for some reason heap_form_tuple is
>> getting called with planSlot's tupdesc not ri_newTupleSlot's.
> The way we copy a
Hi,
On 2023-01-15 18:08:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-01-15 16:40:27 -0500, Tom Lane wrote:
> >> The documentation is correct, what is broken is the code. I'm not
> >> sure when we broke it
>
> > I've not thought through this fully. But after a first look, this
Andres Freund writes:
> On 2023-01-15 16:40:27 -0500, Tom Lane wrote:
>> The documentation is correct, what is broken is the code. I'm not
>> sure when we broke it
> I've not thought through this fully. But after a first look, this might be
> hard to fix without incuring a lot of overhead /
Hi,
On 2023-01-15 16:40:27 -0500, Tom Lane wrote:
> The documentation is correct, what is broken is the code. I'm not
> sure when we broke it
Looks to be an old issue, predating the slot type stuff. It reproduces at
least as far back as 10.
I've not thought through this fully. But after a
Laurenz Albe writes:
> On Tue, 2023-01-10 at 15:53 +, PG Doc comments form wrote:
>>> PLAIN prevents either compression or out-of-line storage; furthermore it
>>> disables use of single-byte headers for varlena types. This is the only
>>> possible strategy for columns of non-TOAST-able data
On Tue, 2023-01-10 at 15:53 +, PG Doc comments form wrote:
> https://www.postgresql.org/docs/devel/storage-toast.html - This is the
> development version.
>
> > PLAIN prevents either compression or out-of-line storage; furthermore it
> > disables use of single-byte headers for varlena types.
14 matches
Mail list logo
