| 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: | Whole Thread | Raw Message | 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 |