Re: PostgreSQL
Curt Sampson <[email protected]> Thu, 2 Feb 2006 10:37:43 +0900 (JST)
| Newsgroups | gmane.os.netbsd.devel.performance |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 1 Feb 2006, Alfred Perlstein wrote: > Database caching algorithms will offer a signifigant advantage over > a simple filesystem LRU. You'd best go study what algorithms are being used in both locations. I don't believe any of the OSes under discussion use a "simple filesystem LRU" any more, and PostgreSQL's cacheing algorithm is perhaps more naive than you think it is. (Oh, but that does remind me, the query optimizer is not at all naive, so you want to make sure you set effective_cache_size appropriately. I'm not sure how many people know about that option.) > Additionally, a larger shared segment reduces the amount of copying > required. True. But compare the cost of a memory copy and the cost of a disk read or write. Now how much do you need to save? > Additionally, a larger shared segment particularly when non-pageable, > will protect the database's cache against errant jobs that blow > through the kernel's cache. Imagine the effect of untarring a large > file suddenly. It depends on the OS and what algorithms its using for its disk buffering. On Solaris, for example, that effect should be very low. Anyway, this has all been discussed to death on the PostgreSQL lists. I suggest you check out the discussions in the FAQs, archives, and so on if you're interested. cjs -- Curt Sampson <[email protected]> +81 90 7737 2974 The power of accurate observation is commonly called cynicism by those who have not got it. --George Bernard Shaw