Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't recall, has it ever been considered to compare the number of
> actual result rows against the estimate computed by the optimizer and then
> draw some conclusions from it? Both numbers should be easily available.
It's been suggested, but doin
What is the postgres process doing? what does iostat show for disk I/O?
from reading this, you are comparing apples->oranges ... are the drives
the same on the non-SMP as the SMP? amount of RAM? speed of CPUs? hard
drive controllers with same amount of cache on them? etc, etc, etc ...
On Thu
"P. Dwayne Miller" <[EMAIL PROTECTED]> writes:
> Any places to look that might explain the results of explain?
http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/performance-tips.html
If you're still confused, feel free to post the query, table schemas,
and EXPLAIN output.
BTW, have yo
Hello, hackers!
I am running postgresql 7.1 on a SMP Linux box. It runs, but it never pass a
loadavg of 0.4, no matter how I try to overload the system.
The same configuration, the same executable, the same test on a non-SMP
machine gives a loadavg of 19.
That means that a Xeon SMP box
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> TODO: add LIKE optimization to use = if constant does not contain any wildcards
Your information is obsolete ... try looking at the EXPLAIN VERBOSE
output for such a query.
regards, tom lane
---
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Dead(HEAP_XMAX_COMMITTED || HEAP_XMIN_INVALID) tuples never
> revive. Live (not dead) tuples never die in Share Lock mode.
Hmm ... so you're relying on the ShareLock to ensure that the state of
the tuple can't change between when heap_fetch checks it an
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> If so, what about increase the dead lock timer proportional to the
> length of the waiting holder queue?
I don't think that's a good idea; it's not solving the problem, only
reducing performance, and in a fairly arbitrary way at that. (The
length of the
> > Also, isn't the WAL format rather bulky to archive hours and hours of?
If it were actually too bulky, then it needs to be made less so, since that
directly affects overall performance :-)
> > I would expect high-level transaction redo records to be much more compact;
> > mixed into the WAL
> > > > I imagine a daemon extracting redo log entries from WAL segments,
> > > > asynchronously. Mixing redo log entries into the WAL allows the WAL
> > > > to be the only synchronous disk writer in the system, a Good Thing.
> > >
> > > This comes up periodically now. WAL currently already h
> Can someone explain why the following query takes 1 second when using
> LIKE and takes 30 seconds when replacing LIKE by = in the WHERE ?
Because there is no optimization built in, that notices, that your
string does not contain a wildcard and would translate the restriction
corresponding
> >> Hm. It doesn't seem that DeadLockCheck is taking very much of the time.
>
> > Isn't the real time big ?
>
> Yes, it sure is, but remember that the guy getting useful work done
> (DeadLockCheck) is having to share the CPU with 999 other processes
> that are waking up on every clock tick for
11 matches
Mail list logo
