| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |
| Date: | 2018-04-19 20:23:58 |
| Message-ID: | 20180419202358.qitge32wpkkrw4ti@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-04-19 16:56:59 -0300, Alvaro Herrera wrote:
> Michael Paquier wrote:
>
> > Then, let's consider the beginning of the first commit fest of v12 as
> > judgement. Implementing radix tree for shared buffers is a long-term
> > project, which has no guarantee to get merged, while a visibly-simple
> > reloptions which helps in some cases...
>
> In the scenario we studied, the truncations were causing periodic
> hiccups which were quite severe.
Was that with the current logic of breaking the truncations into smaller
chunks?
> The truncations were completely
> useless anyway because the table grew back to the original size daily (a
> few dozen GBs I think). That was a lot of unnecessary work, and under
> exclusive lock no less.
FWIW, One goal of the different buffer mapping implementation is to also
make both increasing and decreasing size of relations possible without
an AEL.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-04-19 20:38:02 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |
| Previous Message | Pavel Stehule | 2018-04-19 20:06:45 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |