Alvaro Herrera wrote:
Here is a patch pursuant to there ideas. The main change is that in
GetSnapshotData, a backend is skipped entirely if inVacuum is found to
be true.
Patch applied.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company -
Ühel kenal päeval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian:
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
I don't see how this gives us ability to vacuum more rows, as the
snapshot of a serializable
Bruce Momjian [EMAIL PROTECTED] writes:
Good question. Imagine you have a serializable transaction like
pg_dump, and then you have lots of newer transactions. If pg_dump is
xid=12, and all the new transactions start at xid=30, any row created
and expired between 12 and 30 can be removed
Hannu Krosing wrote:
?hel kenal p?eval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian:
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
I don't see how this gives us ability to vacuum more rows, as the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Good question. Imagine you have a serializable transaction like
pg_dump, and then you have lots of newer transactions. If pg_dump is
xid=12, and all the new transactions start at xid=30, any row created
and expired between 12 and
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, why?
Because it's used to determine the Xmin that our vacuum will use. If
there is a transaction whose Xmin calculation included the Xid of a
transaction running vacuum, we have gained nothing from directly
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, why?
Because it's used to determine the Xmin that our vacuum will use. If
there is a transaction whose Xmin calculation included the Xid of a
transaction running vacuum, we have gained nothing from directly
excluding said
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
But the patch changes things so that *everyone* excludes the vacuum from
their xmin. Or at least I thought that was the plan.
We shouldn't do that, because that Xmin is also used to truncate
SUBTRANS.
Yeah, but you were going to
On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote:
The other POV is that we don't really care about long-running
transaction in other databases unless they are lazy vacuum, a case which
is appropiately covered by the patch as it currently stands. This seems
to be the POV that
[EMAIL PROTECTED] (Jim C. Nasby) writes:
There are other transactions to consider: user transactions that will
run a long time, but only hit a limited number of relations. These are
as big a problem in an OLTP environment as vacuum is.
Rather than coming up with machinery that will
Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby:
On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote:
The other POV is that we don't really care about long-running
transaction in other databases unless they are lazy vacuum, a case which
is appropiately
On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote:
Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby:
There are other transactions to consider: user transactions that will
run a long time, but only hit a limited number of relations. These
are
as big a problem in an OLTP
Jim Nasby wrote:
On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote:
So instead of actually *solving* one problem you suggest *thinking*
about solving the general case ?
We have been *thinking* about dead-space-map for at least three
years by now.
No, I just wanted anyone who was actually
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
But the patch changes things so that *everyone* excludes the vacuum from
their xmin. Or at least I thought that was the plan.
We shouldn't do that, because that Xmin is also used to truncate
SUBTRANS.
Yeah,
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hannu Krossing asked me about his patch to ignore transactions running
VACUUM LAZY in other vacuum transactions. I attach a version of the
patch updated to the current sources.
nonInVacuumXmin seems useless ... perhaps a vestige
Ühel kenal päeval, N, 2006-07-27 kell 19:29, kirjutas Alvaro Herrera:
We could either add it anew, beside nonInVacuumXmin, or replace
nonInVacuumXmin. The difference will be whether we will have something
to be used to vacuum shared relations or not. I think in general,
shared relations
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
version of the computation?
Hmm, not useless at all really -- only a bug of mine. Turns out the
notInVacuumXmin stuff is essential, so I put it back.
Uh, why?
I
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
---
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
version of the computation?
Hmm, not useless at all really -- only a bug of mine. Turns out the
notInVacuumXmin stuff is essential, so I put it
19 matches
Mail list logo
