Re: The documentation for storage type 'plain' actually allows single byte header
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 only
> > > > possible strategy for columns of non-TOAST-able data types.
>
> > > However, it does allow "single byte" headers. How to verify this?
> > > CREATE EXTENSION pageinspect;
> > > CREATE TABLE test(a VARCHAR(1) STORAGE PLAIN);
> > > INSERT INTO test VALUES (repeat('A',10));
> > >
> > > Now peek into the page with pageinspect functions
> > >
> > > SELECT left(encode(t_data, 'hex'), 40) FROM
> > > heap_page_items(get_raw_page('test', 0));
> > >
> > > This returned value of "1741414141414141414141".
>
> > I think that the documentation is wrong. The attached patch removes the
> > offending half-sentence.
>
> 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?
Yours,
Laurenz Albe
Re: The documentation for storage type 'plain' actually allows single byte header
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 whole mechanism was to protect data types for which the C functions haven't been upgraded to support non-traditional varlena headers. So I was worried that this behavior would somehow break those cases (which still exist, eg oidvector and int2vector). However, the thing that actually marks such a datatype is that pg_type.typstorage is PLAIN, and as far as I can find we do still honor that case in full. If that's the case then every tupdesc we ever create for such a column will say PLAIN, so there's no opportunity for the wrong thing to happen. So maybe it's okay to move the goalposts and acknowledge that setting attstorage to PLAIN isn't a complete block on applying toast-related transformations. I wonder though whether short-header is the only case that can slide through. In particular, for "INSERT ... SELECT FROM othertable", I suspect it's possible for a compressed-in-line datum to slide through without decompression. (We certainly must fix out-of-line datums, but that doesn't necessarily mean we undo compression.) So I'm not convinced that the proposed wording is fully correct yet. regards, tom lane
Typo in 2.7 Aggregate Functions
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/tutorial-agg.html Description: Near the end of Chapter 2.7 Aggregate Functions of the documentation, the command FILTER is introduced. The full query is SELECT city, max(temp_lo), count(*) FILTER (WHERE temp_lo < 30) FROM weather GROUP BY city HAVING max(temp_lo) < 40; and the output shows a count value of 5. This is an error. In total we only have 3 rows in the table so far. Furthermore, none of the rows have temp_lo < 30. If I'm not mistaken, the count value should be 0. Thanks, Jimmy
Re: Typo in 2.7 Aggregate Functions
PG Doc comments form writes: > Near the end of Chapter 2.7 Aggregate Functions of the documentation, the > command FILTER is introduced. The full query is > SELECT city, max(temp_lo), count(*) FILTER (WHERE temp_lo < 30) > FROM weather > GROUP BY city > HAVING max(temp_lo) < 40; > and the output shows a count value of 5. This is an error. Yeah :-(. This is already fixed in our source tree [1], as you can see on the website if you look at the "devel" branch. But the released-version docs won't update till our next releases, in February. Thanks for the report, anyway! regards, tom lane [1] https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=f05a5e0003edfec027ee10d09082667036862e1c
