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.
> >>
> >>
>
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 per
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 d
"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 share
>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
"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 broadcast)
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 th
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
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:
INS
> > 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 M
10 matches
Mail list logo
