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 alon
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
> > p
-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
|>
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 investigate
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 long a
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
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
SE
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 t
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
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, 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 a
11 matches
Mail list logo
