On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote:
[EMAIL PROTECTED] wrote:
If the memset
bypasses the cache then the following access will cause a cache line
miss, which can be so slow that using the faster memset can result in a
net performance loss.
Could you
Karel Zak wrote:
On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote:
[EMAIL PROTECTED] wrote:
If the memset
bypasses the cache then the following access will cause a cache line
miss, which can be so slow that using the faster memset can result in a
net performance loss.
Tgl wrote:
As I see it, this means the user-locks (and perhaps all
locks...?) eat around ~ 6k bytes memory each.
They're allocated in groups of 32, which would work out to close to
6k;
maybe you were measuring the incremental cost of allocating the first
one?
I got my 6k figure by
Merlin Moncure [EMAIL PROTECTED] writes:
I was wondering how ~ 10k locks ran me out of shared memory when each
lock takes ~ 260b (half that, as you say) and I am running 8k buffers =
64M.
The number of buffers you have doesn't have anything to do with this.
The question is how much shared
Tom Lane
Merlin Moncure [EMAIL PROTECTED] writes:
According to postgresql.conf, using these settings the lock table eats
64*260*100 bytes = 2M. Well, if it's running my server out of shared
memory, it's eating much, much more shmem than previously thought.
Hmm, the 260 is out of date I
Simon Riggs [EMAIL PROTECTED] writes:
Does this mean that the parameter max_locks_per_transaction isn't honoured
at all, it is just used to size the lock table
Yes, and that's how it's documented.
regards, tom lane
---(end of
On Wed, 2004-09-29 at 21:37, Bruce Momjian wrote:
The reason MemSet is a win is not that the C code is great but because
it eliminates a function call.
A reasonable compiler ought to be able to implement memset() as a
compiler intrinsic where it makes sense to do so. MSVC++ can certainly
do
Neil Conway wrote:
On Wed, 2004-09-29 at 21:37, Bruce Momjian wrote:
The reason MemSet is a win is not that the C code is great but because
it eliminates a function call.
A reasonable compiler ought to be able to implement memset() as a
compiler intrinsic where it makes sense to do so.
good day everyone!
i am using postgresql-8.0beta2-dev3 windows port, with postgis-0.9
add-on. anyway, while trying to insert a table using shp2pgsql, i get
this error:
psql:temp.sql:38: ERROR: Unicode characters greater than or equal to
0x1 are not supported
this is line 38 of temp.sql:
I was hoping this would be in for beta 3, but alas - can someone
*please* commit the win32 version patch at:
http://candle.pha.pa.us/mhonarc/patches/msg0.html
Personally I was holding off in hopes of seeing a cleaner solution.
A patch that requires every executable-building Makefile
10 matches
Mail list logo
