"Jignesh K. Shah" <J.K.Shah@xxxxxxx> writes: > Also very important unless you are running the UPDATE FUNCTIONS which are > separate queries, all these Q1-Q22 Queries are pure "READ-ONLY" queries. > Traditionally I think PostgreSQL does lack "READ-SPEED"s specially since it is > bottlenecked by the size of the reads it does (BLOCKSIZE). Major database > provides multi-block parameters to do multiple of reads/writes in terms of > blocksizes to reduce IOPS and also for read only they also have READ-AHEAD or > prefetch sizes which is generally bigger than multi-block or extent sizes to > aid reads. Note that all of these things are necessitated by those databases using direct i/o of some form or another. The theory is that PostgreSQL doesn't have to worry about these things because the kernel is taking care of it. How true that is is a matter of some debate and it varies from OS to OS. But it's definitely true that the OS will do read-ahead for sequential reads, for example. Incidentally we found some cases that Solaris was particularly bad at. Is there anybody in particular that would be interested in hearing about them? (Not meant to be a knock on Solaris, I'm sure there are other cases Linux or BSD handle poorly too) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
