From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Manfred Koizar <mkoi-pg(at)aon(dot)at>, shridhar_daithankar(at)persistent(dot)co(dot)in, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Buglist |
Date: | 2003-08-26 13:54:55 |
Message-ID: | 3F4B66AF.2030001@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Bruce Momjian wrote:
> Jan Wieck wrote:
>> Manfred Koizar wrote:
>> > On Thu, 21 Aug 2003 21:10:34 +0530, "Shridhar Daithankar"
>> > <shridhar_daithankar(at)persistent(dot)co(dot)in> wrote:
>> >>Point I am trying to make is to tune FSM and autovacuum frequency
>> >>such that you catch all the dead tuples in RAM
>> >
>> > You might be able to catch the pages with dead tuples in RAM, but
>> > currently there's no way to keep VACUUM from reading in all the clean
>> > pages, which can be far more ...
>>
>> Which leads us to a zero gravity vacuum, that does the lazy vacuum for
>> pages currently available in the buffer cache only. And another pg_stat
>> column telling the number of tuples vacuumed so that an autovac has a
>> chance to avoid IO consuming vacuum runs for relations where 99% of the
>> dead tuples have been caught in memory.
>
> What would be really interesting is to look for dead tuples when you
> write/discard a buffer page and add them to the FSM --- that is probably
> the latest time you still have access to the page and has the highest
> probability of being recyclable.
>
True, but it's again in the time critical path of a foreground
application because it's done by a backend who has to read another page
on behalf of a waiting client right now. Also, there is only a small
probability that all the pages required to do the index purge for the
tuples reclaimed are in memory too. Plus there is still no direct
connection between a heap tuples ctid and the physical location of it's
index tuples, so purging an index requires a full scan of it, which is
best done in bulk operations.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Fromm | 2003-08-26 14:06:06 | deleting referenced data |
Previous Message | Mike Mascari | 2003-08-26 13:47:44 | Re: is linux ready for databases ? (Ziff Davis article |
From | Date | Subject | |
---|---|---|---|
Next Message | Mendola Gaetano | 2003-08-26 15:38:48 | Date input changed in 7.4 ? |
Previous Message | Marc G. Fournier | 2003-08-26 06:01:26 | Re: Replication Ideas |