From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Sullivan <andrew(at)libertyrms(dot)info>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Buglist |
Date: | 2003-08-21 02:10:10 |
Message-ID: | 3F442A02.2070608@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>
>>What about a little hint to the buffer management that if it has to
>>evict another buffer to physically read this one (meaning the buffer
>>pool was full already) then it will not put this buffer at the top of
>>the LRU chain but rather at it's end? This way a vacuum on a large table
>>will not cause a complete cache eviction.
>
>
> I think what we really need is a way to schedule VACUUM's I/O at a lower
> priority than normal I/Os. Wouldn't be very portable :-( ... but if the
> OS offers a facility for requesting this, it'd be worth experimenting
> with.
Whatever priority it has, I think the fact that a VACUUM is kicking
everything out of a carefully populated buffer cache and possibly
replacing it with data of low to no interest at all should have some
space for improvement. And that one single optimizer mistake choosing a
seqscan over an index scan for a huge table does the same doesn't strike
me as smart either.
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 | expect | 2003-08-21 02:24:43 | Re: Your details |
Previous Message | jason | 2003-08-21 01:48:34 | Your details |
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2003-08-21 04:07:31 | Re: Buglist |
Previous Message | Christopher Kings-Lynne | 2003-08-21 01:42:45 | Re: Need concrete "Why Postgres not MySQL" bullet list |