Hot Standby tuning for btree_xlog_vacuum()
in [PgSql]
|
Prev: pgsql: Make CheckRequiredParameterValues()depend upon correct
Next: [HACKERS] pg_migrator to /contrib in a later 9.0 beta
From: Tom Lane on 29 Apr 2010 16:20 Simon Riggs <simon(a)2ndQuadrant.com> writes: > Objections to commit? This is not the time to be hacking stuff like this. You haven't even demonstrated that there's a significant performance issue here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jim Nasby on 17 May 2010 14:45 On Apr 29, 2010, at 3:20 PM, Tom Lane wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: >> Objections to commit? > > This is not the time to be hacking stuff like this. You haven't even > demonstrated that there's a significant performance issue here. I tend to agree that this point of the cycle isn't a good one to be making changes, but your performance statement confuses me. If a fairly small patch means we can avoid un-necessary reads why shouldn't we avoid them? -- Jim C. Nasby, Database Architect jim(a)nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 17 May 2010 16:10 Jim Nasby <decibel(a)decibel.org> writes: > On Apr 29, 2010, at 3:20 PM, Tom Lane wrote: >> This is not the time to be hacking stuff like this. You haven't even >> demonstrated that there's a significant performance issue here. > I tend to agree that this point of the cycle isn't a good one to be making changes, but your performance statement confuses me. If a fairly small patch means we can avoid un-necessary reads why shouldn't we avoid them? Well, by "time of the cycle" I meant "the day before beta1". I'm not necessarily averse to making such a change at some point when it would get more than no testing before hitting our long-suffering beta testers. But I'd still want to see some evidence that there's a significant performance improvement to be had. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 17 May 2010 16:33
On Mon, 2010-05-17 at 16:10 -0400, Tom Lane wrote: > Jim Nasby <decibel(a)decibel.org> writes: > > On Apr 29, 2010, at 3:20 PM, Tom Lane wrote: > >> This is not the time to be hacking stuff like this. You haven't even > >> demonstrated that there's a significant performance issue here. > > > I tend to agree that this point of the cycle isn't a good one to be making changes, but your performance statement confuses me. If a fairly small patch means we can avoid un-necessary reads why shouldn't we avoid them? > > Well, by "time of the cycle" I meant "the day before beta1". I'm not > necessarily averse to making such a change at some point when it would > get more than no testing before hitting our long-suffering beta testers. > But I'd still want to see some evidence that there's a significant > performance improvement to be had. That patch only applies to one record type. However, since we've used Greg's design of spidering out to each heap record that can usually mean 150-200 random I/Os per btree delete. That will take some time, perhaps 1s per WAL record of this type on a very large I/O bound table. That's enough to give me cause for concern without performance measurements. To derive such measurements we'd need to instrument each record type, which we don't do right now either. It might be easier to have a look at the patch and see if you think its worth the fuss of measuring it. I don't think this is the patch that will correct the potential/ partially observed context switching issue, but we have yet to recreate that in lab conditions. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |