On Mon, Jul 22, 2024 at 2:20 PM Robert Haas wrote:
> On Mon, Jul 22, 2024 at 1:00 PM Ahmed Yarub Hani Al Nuaimi
> wrote:
> > That is a very useful thread and I'll keep on following it but it is not
> exactly what I'm trying to achieve here.
> > You see, ther
That is a very useful thread and I'll keep on following it but it is not
exactly what I'm trying to achieve here.
You see, there is a great difference between VACUUM FULL CONCURRENTLY and
adding compaction to lazy vacuuming. The main factor here is resource
utilization: a lot of companies have enou
Jul 2024 at 04:00, Ahmed Yarub Hani Al Nuaimi
> wrote:
> > 2- Can you point me to a resource explaining why this might lead to
> index bloating?
>
> No resource links, but if you move a tuple to another page then you
> must also adjust the index. If you have no exclusive lock
Wow I was busy for a controle of days and now I’m again fully committed to
this initiative. These ideas are extremely useful to my. I’ll first start
by reading the old in-place implementation, but meanwhile I have the
following questions:
1- I’m thinking of adding only one simple step to be auto-va
So anyways I talked last week about lock-free vacuum. Since then I almost
finished creating a plugin that works on all Jetbrains products. It hooks
to the internal database tool and displays the internals of the database
and some stats. I would use this for my next phase: autovacuum with
compaction
Hi Robert,
I loved this initiative. Please allow me to introduce myself: I have been
using Postgres for 10 years both as a backend developer connecting to a
Postgres cluster, a DBA, and also I studied thoroughly the code of Postgres
and some plugins. I'm currently working on an ambitious plan to h
Hi guys,
This is inspired by this TODO list
https://wiki.postgresql.org/wiki/Todo#CLUSTER and by pg_repack and
pg_freeze projects.
My final goal is to create an extension that does direct data-file to
data-file transfer (no intermediate tables, no triggers) with no blocking
at all in order to simu
