| From: | Michael Banck <mbanck(at)gmx(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, Ahmed Yarub Hani Al Nuaimi <ahmedyarubhani(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Subject: | Re: Lock-free compaction. Why not? |
| Date: | 2024-07-22 12:42:41 |
| Message-ID: | 669e53c2.050a0220.387ed3.7669@mx.google.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Mon, Jul 22, 2024 at 08:39:23AM -0400, Robert Haas wrote:
> What the extensions that are out there seem to do is, as I understand
> it, an online table rewrite with concurrent change capture, and then
> you apply the changes to the output table afterward. That has the
> problem that if the changes are happening faster than you can apply
> them, the operation does not terminate. But, enough people seem to be
> happy with this kind of solution that we should perhaps look harder at
> doing something along these lines in core.
I believe this is being discussed here:
https://commitfest.postgresql.org/49/5117/
https://www.postgresql.org/message-id/5186.1706694913%40antos
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2024-07-22 12:46:03 | Re: CI, macports, darwin version problems |
| Previous Message | Robert Haas | 2024-07-22 12:39:23 | Re: Lock-free compaction. Why not? |