Re: [PATCHES] Load Distributed Checkpoints, revised patch
On Fri, 2007-06-15 at 13:11 +0200, Michael Paesold wrote: Heikki Linnakangas wrote: Here's an updated WIP version of the LDC patch. I just spreads the writes, that achieves the goal of smoothing the checkpoint I/O spikes. I think sorting the writes etc. is interesting but falls in the category of further development and should be pushed to 8.4. Why do you think so? Is it too much risk to adapt the sorted writes? The numbers shown by ITAGAKI Takahiro looked quite impressive, at least for large shared_buffers configurations. The reactions where rather positive, too. Agreed. Seems like a simple isolated piece of code to include or not. If we controlled it with a simple boolean parameter, that would allow testing during beta - I agree it needs more testing. If we find a way of automating it, cool. If its flaky, strip it out before we release. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Maintaining cluster order on insert
Jaime Casanova [EMAIL PROTECTED] writes: another question: if the fillfactor is 100% then is a complete waste of time to look for a suggested block. maybe we could check for that? No, it isn't, since the page might have been vacuumed since it was last filled up. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Load Distributed Checkpoints, revised patch
Simon Riggs [EMAIL PROTECTED] writes: checkpoint_maxpages would seem like a better name; we've already had those _maxpages settings for 3 releases, so changing that is not really an option (at so late a stage). Sure it is. We've never promised stability of obscure tuning settings. For something as commonly set from-an-application as, say, work_mem (nee sort_mem), it's worth worrying about backward compatibility. But not for things that in practice would only be set from postgresql.conf. It's never been possible to just copy your old .conf file without any thought when moving to a new release. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Load Distributed Checkpoints, revised patch
On Sat, 2007-06-16 at 11:02 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: checkpoint_maxpages would seem like a better name; we've already had those _maxpages settings for 3 releases, so changing that is not really an option (at so late a stage). Sure it is. Maybe, but we need a proposal before we agree to change anything. If we can get rid of them, good, but if we can't I'd like to see a clear posting of the parameters, their meaning and suggested names before we commit this, please. BTW, checkpoint_write_percent actually does what I wanted, but I wasn't able to guess that from the name. checkpoint_duration_percent? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Maintaining cluster order on insert
On 6/16/07, Tom Lane [EMAIL PROTECTED] wrote: Jaime Casanova [EMAIL PROTECTED] writes: another question: if the fillfactor is 100% then is a complete waste of time to look for a suggested block. maybe we could check for that? No, it isn't, since the page might have been vacuumed since it was last filled up. regards, tom lane ahh... that vacuum thing!!! yeah!!! ;) -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [pgsql-www] out of date url in developer faq
Forwarding to -patches. FWIW I looked around a little and couldn't find a
suitable replacement, but if someone knows of one (or can find one) we could
replace the link rather than remove it.
On Friday 15 June 2007 20:23, David Gardner wrote:
I was just reading the pgsql developer faq :
http://www.postgresql.org/docs/faqs.FAQ_DEV.html
and noticed that question 1.11 refers to an out of date url
http://www.benchmarkresources.com/
diff
*** faqs.FAQ_DEV.html-orig Fri Jun 15 17:20:16 2007
--- faqs.FAQ_DEV.html Fri Jun 15 17:21:05 2007
***
*** 512,520
and iTransaction Processing,/i by Jim Gray, Morgan,
Kaufmann/p
- pThere is also a database performance site, with a handbook
- on-line written by Jim Gray at a
href=http://www.benchmarkresources.com/;http://www.benchmarkresources.com
./a./p -
h3 id=item1.121.12) What is configure all about?/h3
pThe files iconfigure/i and iconfigure.in/i are part of
--- 512,517
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Transaction Guarantee, updated version
Completed all of the agreed changes for TG: - WAL writer now runs always, wal_writer_delay = 50ms (default) - when transaction_guarantee = off we record the latest LSN - when we set xact hint bits we look at the latest LSN - added database-level stats to show guaranteed commits - fsync parameter still present - removed logic in XLogInsert to test half-full wal buffers - no DFC cache anymore - retained LSN pass-down to mark clog to allow WAL-flush-before-write Passed all of an afternoons testing with pgbench and make check. make check passes with both settings of transaction_guarantee Re-eyeballed every line of the patch to catch errors Operating parameters are: - transaction_guarantee = on | (off) [USERSET] Normal transactions are guaranteed to have been written to disk before we report COMMIT success back to the user. When the transaction guarantee is relaxed we respond to the user that the transaction has succeeded and defer the write to disk. The walwriter process will ensure that any unguaranteed transactions are written to disk after at most two cycles of the wal_writer_delay. This leaves a short window of data loss that can occur should the database server crash. - wal_writer_delay = 50ms (10-1000) For debug, we have - trace_commit = off | (on) - trace_bg_flush = off | (on) - in this patch, defaults to **on**, but this would be set back to off following review More extensive docs required. Planning a whole new section to explain why its OK and what it means etc., plus additional section in Perf Tips. Code has good comments to explain things. Logic to signal walwriter exists but is not now ever called. Seemed worth keeping until review, at least. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com tg.v19.tar.gz Description: application/compressed-tar ---(end of broadcast)--- TIP 6: explain analyze is your friend
