From: | Rod Taylor <rbt(at)zort(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: possible vacuum improvement? |
Date: | 2002-09-03 15:09:55 |
Message-ID: | 1031065796.43658.42.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2002-09-03 at 11:01, Tom Lane wrote:
> "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
> > 1)Is this sounds like a workable solution?
>
> Adding a trigger to every tuple update won't do at all. Storing the
> counts in a table won't do either, as the updates on that table will
> generate a huge amount of wasted space themselves (not to mention
> enough contention to destroy concurrent performance).
>
> > 4)Is use of threads sounds portable enough?
>
> Threads are completely out of the question, at least if you have any
> hope of seeing this code get accepted into the core distro.
>
>
> For vacuum's purposes all that we really care to know about is the
> number of obsoleted tuples in each table: committed deletes and updates,
> and aborted inserts and updates all count. Furthermore, we do not need
> or want a 100% reliable solution; approximate counts would be plenty
> good enough.
It would be nice if it could track successful inserts, and fire off an
analyze run when it changes more than 20% from what stats says.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-03 15:19:20 | Re: possible vacuum improvement? |
Previous Message | Serguei A. Mokhov | 2002-09-03 15:07:31 | Re: Memory management question |