On Sat, 2008-08-02 at 00:24 -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think it makes sense to commit this patch now, per previous
discussions on which we have agreed to make incremental changes.
Yeah, but at the same time there is merit in the argument that the
Simon Riggs wrote:
The first half is actually quite large, but that makes it even more
sensible to commit this part now.
The enclosed patch introduces the machinery by which we might later
optimise hint bit setting. It differentiates between hint bit setting
and block dirtying, when the
Alvaro Herrera [EMAIL PROTECTED] writes:
I think it makes sense to commit this patch now, per previous
discussions on which we have agreed to make incremental changes.
Yeah, but at the same time there is merit in the argument that the
proposed patch hasn't actually been proven to be usable for
On Mon, 2008-07-21 at 16:33 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-07-21 at 11:36 +0530, Pavan Deolasee wrote:
I think we should try at least one or two possible optimizations and
get some numbers before we jump and make substantial changes to the
code.
On Mon, 2008-07-21 at 11:36 +0530, Pavan Deolasee wrote:
I think we should try at least one or two possible optimizations and
get some numbers before we jump and make substantial changes to the
code.
You know you're suggesting months of tests and further discussion. :-(
I'll fix the bug,
On Fri, 2008-06-27 at 16:02 +0100, Simon Riggs wrote:
The patch splits into two parts:
* the machinery to *not* dirty a page when we set hints
* behaviour modifications now that we can tell the difference between
dirty and hinted pages
Nobody has yet come up with any comments about the
Alvaro Herrera [EMAIL PROTECTED] writes:
If only VACUUM is going to set flexible to off, maybe it's better to
leave the APIs as they are and have a global that's set by VACUUM only
(and reset in a PG_CATCH block).
Ugh. Perhaps it would be simpler to have a wrapper function HTSV() macro which
Simon Riggs [EMAIL PROTECTED] writes:
The default and minimum value for this parameter is 1, so very similar to
existing behaviour. Expected settings would be 2-5, possibly as high as 20,
though those are just educated guesses. So the maximum is set arbitrarily as
100.
Not a fan of arbitrary
On Fri, 2008-06-27 at 15:25 +0100, Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
If only VACUUM is going to set flexible to off, maybe it's better to
leave the APIs as they are and have a global that's set by VACUUM only
(and reset in a PG_CATCH block).
Ugh. Perhaps it
On Fri, 2008-06-27 at 15:36 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The default and minimum value for this parameter is 1, so very similar to
existing behaviour. Expected settings would be 2-5, possibly as high as 20,
though those are just educated guesses. So
Gregory Stark wrote:
I'm also a bit concerned that *how many hint bits* isn't enough information to
determine how important it is to write out the page.
Agreed, that doesn't seem like a very good metric to me either.
Or how many *unhinted* xmin/xmax
values were found? If HTSV can hint xmin
On Wed, 2008-06-18 at 23:41 +0100, Simon Riggs wrote:
New version on its way.
New version complete, but I'm doing some more performance profiling
before submitting next version. If anybody is waiting, just shout and
I'll post the current version.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs wrote:
When running a VACUUM command we always dirty the block when setting
hint bits, for a number of reasons:
* VACUUM FULL expects all hint bits to be set prior to moving tuples
* Setting all hint bits allows us to truncate the clog
* it forces the VACUUM to write out its own
13 matches
Mail list logo
