Re: [PERFORM] lru_multiplier and backend page write-outs

s, I am nore interesting in understanding better what is happening and having better indications of when backends block on I/O, than necessarily having a proven improvement in throughput or latency. It makes it easier to reason about what is happening when you *do* have a measured performanc

Re: [PERFORM] Occasional Slow Commit

ares.) -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgpVeeaouHlTg.pgp Description: PGP signature

Re: [PERFORM] lru_multiplier and backend page write-outs

rite-outs). On a system where you really want to keep backend writes to exactly 0 under normal circumstances (discounting vacuuming), and having a large buffer cache (say the one gig), it might be nice to be able to say "ok - I have 1 GB of buffer cache. for the purpose of the JIT algorithm, ple

[PERFORM] lru_multiplier and backend page write-outs

p://www.westnet.com/~gsmith/content/postgresql/chkp-bgw-83.htm -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgpq5Wyr2Jr4u.pgp Description: PGP signature

Re: [PERFORM] Large number of tables slow insert

6-7 MB/second would be fairly consistent with INSERT/COPY operations being CPU bound on a modern CPU, in my experience. It may be that this is entirely untrue in your case, but it sounds like a reasonable thing to at least consider. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schull

Re: [PERFORM] NOW vs CURRENT_DATE

t. Also, NOW() is equivalent to CURRENT_TIMESTAMP() rather than CURRENT_DATE(). Perhaps the date vs. timestamp has some implication of how they query is planned. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Ma

[PERFORM] Identifying the nature of blocking I/O

oller. Is there currently a way of dumping such information? I.e., asking PG "what are backends waiting on right now?". -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

Tom, for the very insightful discussion! -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgppa59ys6aP0.pgp Description: PGP signature

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

short periods of time even for things that are officially declared non-blocking; the question is whether this falls into this category.) -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

informative response. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgpUjtABeKgmx.pgp Description: PGP signature

[PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

x releases above .4, and the 8.3 releases, but did not see anything that indicated locking/conflict related fixes in relation to vacuums. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [

Re: [PERFORM] shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine

uld require flushing the data in question first (i.e., normally you just fsync the WAL, but when you want to recycle space you need fsync() for the barrier and are then free to nuke the old WAL). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'

Re: [PERFORM] shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine

nd make appropriate decisions. Or is it a matter of PostgreSQL doing non-direct I/O, such that anything cached in shared_buffers will also be cached by the OS? -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL

[PERFORM] shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine

- the database working set is larger than RAM it would be generally advisable to pump up shared_buffers pretty much as far as possible instead of relying on the buffer cache? -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Sen

[PERFORM] Non-blocking vacuum full

R when you want it for reasons other than perfect order ("mostly sorted"). Opinions/thoughts? -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgpFbOXmSf908.pgp Description: PGP signature

Re: [PERFORM] max_fsm_pages, shared_buffers and checkpoint_segments

ve the RC script will cause the message to be printed interactively at the console too, if you run it. (Assuming you are using it installed from ports). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED]

Re: [PERFORM] Postgres Benchmark Results

ible I could get all the performance benefit without the code complexity, and with no penalty (because in this case persistence is not important). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED]

Re: [PERFORM] Scaling SELECT:s with the number of disks on a stripe

I explicitly did not want to turn it up so that I could benchmark the raw performance of disk I/O, rather than having things be cached in memory more than it would already be. But apparantly it had other side-effects I did not consider. Thanks again, -- / Peter Schuller PGP userID: 0xE9758B7D or

Re: [PERFORM] Scaling SELECT:s with the number of disks on a stripe

rspace vs. kernelspace CPU concerns (since obviously the data being worked on is in RAM). Or am I missing something? It is worth noting that the SELECT of fewer entries is entirely disk bound; there is almost no CPU usage whatsoever. Even taking the cumulative CPU usage into account (gut feeli

Re: [PERFORM] Scaling SELECT:s with the number of disks on a stripe

he index for a few tens of thousands of entries sounds a bit excessive. Or does it not? Because at that level, the CPU bound period alone is approaching the time it would take to seek for each entry instead. But then I presume the amount of work is similar/the same for the other case, except it's

Re: [PERFORM] Scaling SELECT:s with the number of disks on a stripe

ful in some other context down the road. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgp2AH9xvZCzu.pgp Description: PGP signature

[PERFORM] Scaling SELECT:s with the number of disks on a stripe

ed to be doing that would increase performance above a "seek once per matching row" plan? I haven't been able to Google my way to what the intended benefit is of a heap scan vs. a plain index scan. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]