| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
| Date: | 2024-02-21 11:19:29 |
| Message-ID: | CAEze2WgNHTWfw_bP6O0zW_=vi1D-yi1nh6-JDj9kd=8UaB-zLA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 21 Feb 2024 at 09:35, Michail Nikolaev
<michail(dot)nikolaev(at)gmail(dot)com> wrote:
>
> One more idea - is just forbid HOT prune while the second phase is
> running. It is not possible anyway currently because of snapshot held.
>
> Possible enhancements:
> * we may apply restriction only to particular tables
> * we may apply restrictions only to part of the tables (not yet
> scanned by R/CICs).
>
> Yes, it is not an elegant solution, limited, not reliable in terms of
> architecture, but a simple one.
How do you suppose this would work differently from a long-lived
normal snapshot, which is how it works right now?
Would it be exclusively for that relation? How would this be
integrated with e.g. heap_page_prune_opt?
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2024-02-21 11:24:54 | Re: A problem about partitionwise join |
| Previous Message | Matthias van de Meent | 2024-02-21 11:01:45 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |