| From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Extent Locks |
| Date: | 2013-05-28 13:38:05 |
| Message-ID: | CAJKUy5iGVyLxDMJ+vvYV9zjhTS+Djz=+oY+eXb701za_htEDog@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 28, 2013 at 7:36 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> On the other hand, I do feel like people are worried about
> over-extending a relation and wasting disk space- but with the way that
> vacuum can clean up pages at the end, that would only be a temporary
> situation anyway.
>
Hi,
Maybe i'm wrong but this should be easily solved by an
autovacuum_no_truncate_empty_pages or an autovacuum_empty_pages_limit
GUC/reloption.
Just to clarify the second one autovacuum will allow until that limit
of empty pages, and will remove excess from there
We can also think in GUC/reloption for next_extend_blocks so formula
is needed, or of course the automated calculation that has been
proposed
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-05-28 13:39:26 | Re: MVCC catalog access |
| Previous Message | Bruce Momjian | 2013-05-28 13:34:57 | Re: ASYNC Privileges proposal |