Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, no, that's not very clear. A long-running transaction will be a
VACUUM bottleneck because of its own XID, never mind its xmin.
Well, my secondary addition was to start MyProc-xmin with the current
xid
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, my secondary addition was to start MyProc-xmin with the current
xid counter, rather than your own xid.
Don't tell me you seriously believe that would work.
I do. Please tell me why it
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, my secondary addition was to start MyProc-xmin with the current
xid counter, rather than your own xid.
Don't tell me you seriously believe that would work.
I do.
On Fri, 2007-03-23 at 17:35 -0400, Tom Lane wrote:
To make intra-transaction advancing of xmin possible, we'd need to
explicitly track all of the backend's live snapshots, probably by
introducing a snapshot cache manager that gives out tracked
refcounts
as we do for some other structures like
On Sat, 2007-03-24 at 11:48 -0400, Tom Lane wrote:
Also, at some point a long-running transaction becomes a bottleneck
simply because its XID is itself the oldest thing visible in the
ProcArray and is determining everyone's xmin. How much daylight is
there really between your xmin is old and
Simon Riggs [EMAIL PROTECTED] writes:
Did Heikki's patch to move the xmin forward during VACUUM get rejected?
That seems like it has a much wider use case.
It's still in the queue (which I have finally started to review in
earnest).
regards, tom lane
Simon Riggs wrote:
On Sat, 2007-03-24 at 11:48 -0400, Tom Lane wrote:
Also, at some point a long-running transaction becomes a bottleneck
simply because its XID is itself the oldest thing visible in the
ProcArray and is determining everyone's xmin. How much daylight is
there really
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
How much does it cost to optimise for this case?
Zero cost. It involves just tracking if there are any old snapshots,
I will be fascinated to hear how you define that as zero cost. It might
be relatively low, but it's not zero, and
This is an optimization so I was thinking of something simpler, like
incrementing/decrementing a counter every time we allocate/free a
snapshot (like in the patch), and updating MyProc-xmin only if there
are no open snapshots. I don't think it is worth tracking anything more
complicated than
Bruce Momjian [EMAIL PROTECTED] writes:
This is an optimization so I was thinking of something simpler, like
incrementing/decrementing a counter every time we allocate/free a
snapshot (like in the patch), and updating MyProc-xmin only if there
are no open snapshots. I don't think it is worth
Tom Lane wrote:
On the whole though I think we should let this idea go till 8.4; we have
a lot to deal with for 8.3 and a definite shortage of evidence that
advancing xmin will buy much. Mu gut feeling is that the above design
would save about enough in snapshot-copying costs to pay for its
I have a question about what would happen for a transaction running a command
like COPY FROM. Is it possible it would manage to arrange to have no live
snapshots at all? So it would have no impact on concurrent VACUUMs? What about
something running a large pg_restore?
Tom Lane [EMAIL PROTECTED]
Gregory Stark wrote:
I have a question about what would happen for a transaction running a command
like COPY FROM. Is it possible it would manage to arrange to have no live
snapshots at all? So it would have no impact on concurrent VACUUMs? What about
something running a large pg_restore?
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
... but we won't come out ahead unless advancing xmin
intra-transaction really helps, and I'm not sure I believe that (except
in the special case of VACUUM, and we already have a solution for that,
which would be independent of this).
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
I have a question about what would happen for a transaction running a command
like COPY FROM. Is it possible it would manage to arrange to have no live
snapshots at all? So it would have no impact on concurrent VACUUMs? What
about
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
... but we won't come out ahead unless advancing xmin
intra-transaction really helps, and I'm not sure I believe that (except
in the special case of VACUUM, and we already have a solution for that,
which would be
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, no, that's not very clear. A long-running transaction will be a
VACUUM bottleneck because of its own XID, never mind its xmin.
Well, my secondary addition was to start MyProc-xmin with the current
xid counter, rather than your own
Gregory Stark [EMAIL PROTECTED] writes:
Well I think this would be the same infrastructure we would need to do
the other discussed improvement to address pg_dump's impact. That
would require us to publish the youngest xmax of the live
snapshots. Vacuum could deduce that that xid cannot
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Well I think this would be the same infrastructure we would need to do
the other discussed improvement to address pg_dump's impact. That
would require us to publish the youngest xmax of the live
snapshots. Vacuum
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have been thinking we could improve how quickly VACUUM can expire rows
if we update procArray.xmin more frequently for non-SERIALIZABLE
transactions.
The attached patch updates procArray.xmin in this manner.
This
Heikki Linnakangas [EMAIL PROTECTED] writes:
It seems to me a lot cleaner to do the reference counting like Tom
suggested. Increase the refcount on CopySnapshot, and decrease it on
FreeSnapshot. Assuming that all callers of CopySnapshot free the
snapshot with FreeSnapshot when they're done
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
It seems to me a lot cleaner to do the reference counting like Tom
suggested. Increase the refcount on CopySnapshot, and decrease it on
FreeSnapshot. Assuming that all callers of CopySnapshot free the
snapshot with
OTOH, do we have any evidence that this is worth bothering with at all?
I fear that the cases of long-running transactions that are problems
in the real world wouldn't be helped much --- for instance, pg_dump
wouldn't change behavior because it uses a serializable transaction.
Well I think
Bruce Momjian wrote:
The attached patch updates procArray.xmin in this manner. Here is an
example of how the patch improves dead row reuse:
I don't think this really works. Consider what happens if I change
session 2 this way:
Session #:
1 2
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have been thinking we could improve how quickly VACUUM can expire rows
if we update procArray.xmin more frequently for non-SERIALIZABLE
transactions.
The attached patch updates procArray.xmin in this manner.
This patch is
25 matches
Mail list logo
