From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Anything to be gained from a 'Postgres Filesystem'? |
Date: | 2004-11-04 15:47:31 |
Message-ID: | 60bred39bg.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
lists(at)boutiquenumerique(dot)com (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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Barnard | 2004-11-04 16:00:38 | Re: [PERFORM] Restricting Postgres |
Previous Message | Tom Lane | 2004-11-04 14:52:03 | Re: index not used if using IN or OR |