On Thu, 2004-11-04 at 23:29, Pierre-Frédéric Caillaud wrote:
>       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.

Uh, which "sleep" are you referring to?

Also, how would interacting with the filesystem's journal effect how
often we need to force-write the WAL to disk? (ISTM we need to sync
_something_ to disk when a transaction commits in order to maintain the
WAL invariant.)

>       There's fadvise to tell the OS to readahead on a seq scan (I think the OS  
> detects it anyway)

Not perfectly, though; also, Linux will do a more aggressive readahead
if you tell it to do so via posix_fadvise().

> if there was a system call telling the OS "in the  
> next seconds I'm going to read these chunks of data from this file (gives  
> a list of offsets and lengths), could you put them in your cache in the  
> most efficient order without seeking too much, so that when I read() them  
> in random order, they will be in the cache already ?".


        Specifies that the application expects to access the specified
        data in the near future.


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to