On Sat, 9 Oct 2004, Tom Lane wrote:
mmap provides msync which is comparable to fsync, but AFAICS it
provides no way to prevent an in-memory change from reaching disk too
soon. This would mean that WAL entries would have to be written *and
flushed* before we could make the data change at all,
Brock Henry wrote:
Any comments/suggestions would be appreciated.
Tune also the disk I/O elevator.
look at this: http://www.varlena.com/varlena/GeneralBits/49.php
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: you can get off all lists at
On Sat, Oct 23, 2004 at 12:31:32PM +0200, Gaetano Mendola wrote:
Any comments/suggestions would be appreciated.
Tune also the disk I/O elevator.
look at this: http://www.varlena.com/varlena/GeneralBits/49.php
Mm, interesting. I've heard somewhere that the best for database-like loads
on
Josh Berkus wrote:
Tom,
The bigger problem here is that the SMP locking bottlenecks we are
currently seeing are *hardware* issues (AFAICT anyway). The only way
that futexes can offer a performance win is if they have a smarter way
of executing the basic atomic-test-and-set sequence than we do;
Any time you run subqueries, it's going to slow down the update
process a lot. Each record that is updated in source_song_title runs
two additional queries. When I do large updates like this, I usualy
Run a transaction that will select all the new data into a new table
on a join. For example
Curt Sampson [EMAIL PROTECTED] writes:
Back when I was working out how to do this, I reckoned that you could
use mmap by keeping a write queue for each modified page. Reading,
you'd have to read the datum from the page and then check the write
queue for that page to see if that datum had been
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I proposed weeks ago to see how the CSStorm is affected by stick each
backend in one processor ( where the process was born ) using the
cpu-affinity capability ( kernel 2.6 ), is this proposal completely
out of mind ?
That was investigated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Berkus wrote:
| Gaetano,
|
|
|I proposed weeks ago to see how the CSStorm is affected by stick each
|backend in one processor ( where the process was born ) using the
|cpu-affinity capability ( kernel 2.6 ), is this proposal completely out of
On Tue, Oct 19, 2004 at 11:40:17AM -0400, Rod Taylor wrote:
Whatever the case, the database still slows down to a halt after a month or
so, and I have to go in and shut everything down and do a VACUUM FULL by
hand. One index (of many many) takes 2000 seconds to vacuum. The whole
process
On Sat, 23 Oct 2004, Tom Lane wrote:
Seems to me the overhead of any such scheme would swamp the savings from
avoiding kernel/userspace copies ...
Well, one really can't know without testing, but memory copies are
extremely expensive if they go outside of the cache.
the locking issues alone
10 matches
Mail list logo
