| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Floris Van Nee <florisvannee(at)optiver(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: non-HOT update not looking at FSM for large tuple update |
| Date: | 2021-03-17 20:51:48 |
| Message-ID: | CAFBsxsG8WWq9oNFbQon3rBPWTYrQSwYNmzjbp8a92BCg6vO5iQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 12, 2021 at 8:45 AM Matthias van de Meent <
boekewurm+postgres(at)gmail(dot)com> wrote:
>
> If this case isn't added, the lower else branch will fail to find
> fitting pages for len > maxPaddedFsmRequest tuples; potentially
> extending the relation when there is actually still enough space
> available.
Okay, with that it looks better to go back to using Max().
Also in v4:
- With the separate constant you suggested, I split up the comment into two
parts.
- I've added a regression test to insert.sql similar to your earlier test,
but we cannot use vacuum, since in parallel tests there could still be
tuples visible to other transactions. It's still possible to test
almost-all-free by inserting a small tuple.
- Draft commit message
--
John Naylor
EDB: http://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-Fix-bug-in-heap-space-management-that-was-overly-.patch | application/octet-stream | 6.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2021-03-17 20:55:02 | Re: WIP: BRIN multi-range indexes |
| Previous Message | Simon Riggs | 2021-03-17 20:50:27 | Re: VACUUM (DISABLE_PAGE_SKIPPING on) |