[EMAIL PROTECTED] (Pierre-Frédéric Caillaud) writes: >> posix_fadvise(2) may be a candidate. Read/Write bareers another pone, as >> well asn syncing a bunch of data in different files with a single call >> (so that the OS can determine the best write order). I can also imagine >> some interaction with the FS journalling system (to avoid duplicate >> efforts). > > There is also the fact that syncing after every transaction > could be changed to syncing every N transactions (N fixed or > depending on the data size written by the transactions) which would > be more efficient than the current behaviour with a sleep. HOWEVER > suppressing the sleep() would lead to postgres returning from the > COMMIT while it is in fact not synced, which somehow rings a huge > alarm bell somewhere. > > What about read order ? > This could be very useful for SELECT queries involving > indexes, which in case of a non-clustered table lead to random seeks > in the table.
Another thing that would be valuable would be to have some way to say: "Read this data; don't bother throwing other data out of the cache to stuff this in." Something like a "read_uncached()" call... That would mean that a seq scan or a vacuum wouldn't force useful data out of cache. -- let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];; http://www.ntlug.org/~cbbrowne/linuxxian.html A VAX is virtually a computer, but not quite. ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
