Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-09-04 Thread Bruce Momjian
Manfred Koizar wrote: > [ still brainstorming ... ] > > On Thu, 21 Aug 2003 17:16:50 -0400, Tom Lane <[EMAIL PROTECTED]> > wrote: > >> Whenever a backend encounters a dead tuple it inserts a reference to > >> its page into the RSM. > > > >This assumes that backends will visit dead tuples with sign

Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-08-28 Thread Tom Lane
[EMAIL PROTECTED] (Grant Succeeded) writes: > The best for me by far, is to get the OS to *not* cache stuff. As > long as the database uses the information it inherently has available, > it can make far more effective use of the same amount of memory the OS > would have used to cache the whole fil

Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-08-28 Thread Grant Succeeded
[EMAIL PROTECTED] (Tom Lane) wrote in message news:<[EMAIL PROTECTED]>... > Manfred Koizar <[EMAIL PROTECTED]> writes: > > better. AFAICS Vivek's problem is that it is hard enough to hold a > > good part of the working set in the cache, and still his disks are > > saturated. Now a VACUUM not only

Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-08-26 Thread Curt Sampson
On Thu, 21 Aug 2003, Tom Lane wrote: > We have had some people looking at improved buffer management > algorithms; LRU-2 or something smarter would help. I dunno whether > we can dissuade the kernel from flushing its cache though. Using open/read/write system calls, you can't. You can always use

Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-08-25 Thread Tom Lane
Manfred Koizar <[EMAIL PROTECTED]> writes: > Good point. What about: Whenever a backend *deletes* a tuple it > inserts a reference to its page into the RSM? Then an entry in the > RSM doesn't necessarily mean that the referenced page has reclaimable > space, but it would still be valueable infor

Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-08-25 Thread Tom Lane
Manfred Koizar <[EMAIL PROTECTED]> writes: > better. AFAICS Vivek's problem is that it is hard enough to hold a > good part of the working set in the cache, and still his disks are > saturated. Now a VACUUM not only adds one more process to disk I/O > contention, but also makes sure that the work

Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-08-21 Thread Manfred Koizar
On Thu, 21 Aug 2003 17:56:02 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >Conceivably it could be a win, though, >if you could do frequent "vacuum decent"s and only a full-scan vacuum >once in awhile (once a day maybe). That's what I had in mind; similar to the current situation where you can avoid

Re: [HACKERS] Decent VACUUM (was: Buglist)

2003-08-21 Thread Manfred Koizar
[ still brainstorming ... ] On Thu, 21 Aug 2003 17:16:50 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >> Whenever a backend encounters a dead tuple it inserts a reference to >> its page into the RSM. > >This assumes that backends will visit dead tuples with significant >probability. I doubt that as

[HACKERS] Decent VACUUM (was: Buglist)

2003-08-21 Thread Manfred Koizar
On Wed, 20 Aug 2003 15:39:26 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >But I think the real point here is that there's no reason to think that >doing tuple deletion on-the-fly in foreground transactions is superior >to doing it in background with a vacuum process. You're taking what >should be n