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 tha
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
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
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
Tom Lane wrote:
> 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 imp
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,
> >> w
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
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
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
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
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 it
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
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 th
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,
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 r
"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
-
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
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 structure
"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
>> snapshot
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 po
> 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
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
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
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
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 pat
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 incredibly broken. Didn
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
VACUUM treats dead tuple with an xmax less than all procArray.xmin's as
invisible with space ready to be reused.
Right now, we set procArray.xmin at transaction start to the required
SERIALIZABLE value. We currently don't update procArray.xmin when we
know we are in a READ COMMITTED transaction,
28 matches
Mail list logo
