On Thu, Jul 24, 2008 at 9:06 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> I suspect this is not the root problem, but one solution to it.
Agreed. It is not the root problem. However, until DSM is fully
implemented and working, not having the ability to gather statistics
during long vacuums is pr
On Mon, 2008-07-21 at 17:50 -0400, Jonah H. Harris wrote:
> Currently, one cannot perform a concurrent VACUUM and ANALYZE. This
> is a significant problem for tables which are not only large and have
> designated cost-delays, but which are also heavily inserted into and
> deleted from.
I suspect
Jonah H. Harris wrote:
On Mon, Jul 21, 2008 at 10:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
The case I'm looking at is a large table which requires a lazy vacuum,
and a zero vacuum cost delay would cause too much I/O. Yet, this
table has enough in
On Tue, Jul 22, 2008 at 12:31 AM, Matthew T. O'Connor <[EMAIL PROTECTED]> wrote:
>> Is DSM going to be in 8.4? The last I had heard, DSM+related
>> improvements weren't close to being guaranteed for this release. If
>> it doesn't make it, waiting another year and a half for something
>> easily fi
Jonah H. Harris wrote:
On Mon, Jul 21, 2008 at 10:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
I don't find this a compelling argument, at least not without proof that
the various vacuum-improvement projects already on the radar screen
(DSM-driven vacuum, etc) aren't going to fix your problem.
On Mon, Jul 21, 2008 at 10:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>> The case I'm looking at is a large table which requires a lazy vacuum,
>> and a zero vacuum cost delay would cause too much I/O. Yet, this
>> table has enough insert/delete acti
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> The case I'm looking at is a large table which requires a lazy vacuum,
> and a zero vacuum cost delay would cause too much I/O. Yet, this
> table has enough insert/delete activity during a vacuum, that it
> requires a fairly frequent analysis to main
On Mon, Jul 21, 2008 at 7:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>> Because we wouldn't want multiple ANALYZEs running on the same table,
>> changing the lock back to an AccessShareLock doesn't sound like a
>> solution.
>
> It flat will not work.
On Mon, Jul 21, 2008 at 6:15 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> This means that VACUUM ANALYZE must grab both locks ... is there a
> gotcha here?
Agreed.
> The main problem I see with this idea is that the dead and total tuple
> count computed by ANALYZE would be immediately out of d
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Because we wouldn't want multiple ANALYZEs running on the same table,
> changing the lock back to an AccessShareLock doesn't sound like a
> solution.
It flat will not work. We used to do it that way, and it didn't
(search for "tuple concurrently upd
Jonah H. Harris escribió:
> Currently, one cannot perform a concurrent VACUUM and ANALYZE. This
> is a significant problem for tables which are not only large and have
> designated cost-delays, but which are also heavily inserted into and
> deleted from. After performing a quick cursory investiga
Currently, one cannot perform a concurrent VACUUM and ANALYZE. This
is a significant problem for tables which are not only large and have
designated cost-delays, but which are also heavily inserted into and
deleted from. After performing a quick cursory investigation on this,
it doesn't appear to
12 matches
Mail list logo
