Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> 1. Grab the AutovacSchedule LWLock exclusively.
> >> 2. Check to see if another worker is currently processing
> >> that table; if so drop LWLock and go to next list entry.
> >> 3. Recompute whether table needs va
Tom Lane <[EMAIL PROTECTED]> wrote:
> Who said anything about external schedulers? I remind you that this is
> AUTOvacuum. If you want to implement manual scheduling you can still
> use plain 'ol vacuum commands.
I think we can split autovacuum into two (or more?) functions:
task gatherers and
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> In any case, I still haven't seen a good case made why a global work
>> queue will provide better behavior than each worker keeping a local
>> queue.
> If we have some external vacuum schedulers, we need to see a
Tom Lane <[EMAIL PROTECTED]> wrote:
> In any case, I still haven't seen a good case made why a global work
> queue will provide better behavior than each worker keeping a local
> queue. The need for small "hot" tables to be visited more often than
> big tables suggests to me that a global queue w
Galy Lee <[EMAIL PROTECTED]> writes:
> We can use the fix-size share memory to maintain such a queue. The
> maximum task size is the number of all tables. So the size of the queue
> can be the same with max_fsm_relations which is usually larger than the
> numbers of tables and indexes in the cluste
Hi, Alvaro
Alvaro Herrera wrote:
> keep such a task list in shared memory, because we aren't able to grow
> that memory after postmaster start.
We can use the fix-size share memory to maintain such a queue. The
maximum task size is the number of all tables. So the size of the queue
can be the sa
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 1. Grab the AutovacSchedule LWLock exclusively.
>> 2. Check to see if another worker is currently processing
>> that table; if so drop LWLock and go to next list entry.
>> 3. Recompute whether table needs vacuuming; if not,
>> drop LWL
Tom Lane wrote:
> I suggest that maybe we don't need exposed TODO lists at all. Rather
> the workers could have internal TODO lists that are priority-sorted
> in some way, and expose only their current table OID in shared memory.
> Then the algorithm for processing each table in your list is
>
>
Alvaro Herrera wrote:
> worker to-do list
> -
>
> When each worker starts, it determines which tables to process in the
> usual fashion: get pg_autovacuum and pgstat data and compute the
> equations.
>
> The worker then takes a "snapshot" of what's currently going on in the
> dat
Galy Lee wrote:
>
> Alvaro Herrera wrote:
> >worker to-do list
> >-
> >It removes from its to-do list the tables being processed. Finally, it
> >writes the list to disk.
>
> I am worrying about the worker-to-do-list in your proposal. I think
> worker isn't suitable to maintain an
Galy Lee <[EMAIL PROTECTED]> writes:
> I am worrying about the worker-to-do-list in your proposal. I think
> worker isn't suitable to maintain any vacuum task list; instead
> it is better to maintain a unified vacuum task queue on autovacuum share
> memory.
Shared memory is fixed-size.
Alvaro Herrera wrote:
>worker to-do list
>-
>It removes from its to-do list the tables being processed. Finally, it
>writes the list to disk.
I am worrying about the worker-to-do-list in your proposal. I think
worker isn't suitable to maintain any vacuum task list; instead
it is
Tom Lane wrote:
"Matthew T. O'Connor" writes:
It's not clear to me why a worker cares that there is a new worker,
since the new worker is going to ignore all the tables that are already
claimed by all worker todo lists.
That seems wrong to me, since it means that new workers will ignore
tabl
"Matthew T. O'Connor" writes:
> Does a new worker really care about the PID of other workers or what
> table they are currently working on?
As written, it needs the PIDs so it can read in the other workers' todo
lists (which are in files named by PID).
> It's not clear to me why a worker cares
My initial reaction is that this looks good to me, but still a few
comments below.
Alvaro Herrera wrote:
Here is a low-level, very detailed description of the implementation of
the autovacuum ideas we have so far.
launcher's dealing with databases
-
[ Snip ]
Here is a low-level, very detailed description of the implementation of
the autovacuum ideas we have so far.
launcher's dealing with databases
-
We'll add a new member "nexttime" to the autovac_dbase struct, which
will be the time_t of the next time a worker needs
16 matches
Mail list logo
