From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: pg_autovacuum integration attempt #2 |
Date: | 2004-07-12 14:36:35 |
Message-ID: | 40F2A1F3.6000808@zeut.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Peter Eisentraut wrote:
> Bruce Momjian wrote:
>>I have added this patch plus your later comments to the patch queue.
>
> The autovacuum process still uses libpq to send its queries, which is
> not the idea behind backend integration.
Actually, I intentionally had pg_autovacuum continue to use libpq based
Tom's advise. Please see this thread:
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00931.php
And more specifically, these follow ups:
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00989.php
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00992.php
The short of it is that Tom felt having the autovac daemon continue to
use libpq keeps "autovac control code still at arms length from the backend"
To me the main benifit of having pg_autovacuum integrated in as a
backend process is not eliminating libpq from the process, but rather:
* access to GUC, elog (and other things)
* allows autovac to be started and shutdown by the backend based on a
GUC variable
* allows autovac to have it's own system table to maintain it's data
across restarts
* eventually should allow vacuum decisions to be based on factors beyond
the stats system (FSM etc...)
IMHO, the use of libpq is not a bug, it's a feature.
Thoughts?
Matthew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-12 14:53:54 | Re: pg_autovacuum integration attempt #2 |
Previous Message | Bruce Momjian | 2004-07-12 14:35:54 | Re: add missing options to pg_dumpall |