From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PostgreSQL 17 Beta 1 release announcement draft |
Date: | 2024-05-16 02:42:37 |
Message-ID: | CAApHDvoUNLM3mnNU9Jt3qLKH-HEwgvF0ost3D4_t0R7c-+ipKg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for writing that up. It's always exciting to see this each year.
On Thu, 16 May 2024 at 13:45, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> * Please indicate if you believe there's a notable omission, or if we
> should omit any of these callouts
I'd say the streaming read stuff added in b5a9b18cd and subsequent
commits like b7b0f3f27 and 041b96802 are worth a mention. I'd be happy
to see this over the IS NOT NULL qual stuff that I worked on in there
or even the AVX512 bit counting. Speeding up a backwater aggregate
function is nice, but IMO, not compatible with reducing the number
reads.
There's some benchmarking in a youtube video:
https://youtu.be/QAYzWAlxCYc?si=L0UT6Lrf067ZBv46&t=237
> * Please indicate if a description is confusing - I'm happy to rewrite
> to ensure it's clearer.
>
> Please provide feedback no later than Wed 2024-05-22 18:00 UTC.
The only other thing I saw from a quick read was a stray "the" in "the
copy proceed even if the there is an error inserting a row."
David
From | Date | Subject | |
---|---|---|---|
Next Message | Yuya Watari | 2024-05-16 02:44:45 | Re: [PoC] Reducing planning time when tables have many partitions |
Previous Message | jian he | 2024-05-16 02:39:18 | Re: First draft of PG 17 release notes |