This is just an update against CVS because there was a conflict due to the
configure Kerberos change.
There is one bug fix in indextuple.c. I need to think a bit on how to write a
regression test to test it.
I'll try to attach the patch as an attachment this time, crossing my fingers.
varvarl
Jeremy Drake <[EMAIL PROTECTED]> writes:
> This version of the patch includes documentation changes. Please
> review...
Applied with minor revisions --- in particular, I thought the initial
owner of a language should be its creator, full stop, rather than the
rather strange (and undocumented) beh
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
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
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> [ IDENTITY/GENERATED patch ]
I got around to reviewing this today.
> - unique index checks are done in two steps
> to avoid inflating the sequence if a unique index check
> is failed that doesn't reference the IDENTITY column
This is just not
"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 r
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,
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
On Mon, 26 Mar 2007, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > This version of the patch includes documentation changes. Please
> > review...
>
> Applied with minor revisions --- in particular, I thought the initial
> owner of a language should be its creator, full stop, rath
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
Jeremy Drake <[EMAIL PROTECTED]> writes:
> On Mon, 26 Mar 2007, Tom Lane wrote:
>> Applied with minor revisions --- in particular, I thought the initial
>> owner of a language should be its creator, full stop, rather than the
>> rather strange (and undocumented) behavior you had.
> The reason I di
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
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
Jeremy Drake wrote:
> On Thu, 22 Mar 2007, Tom Lane wrote:
>
> > AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
> > datatypes) is lack of obvious usefulness. A function dealing with a
> > "text *" doesn't normally have reason to convert that to a Datum until
> > it return
Greg, do you want to submit a patch for this or add a TODO item for this?
---
Gregory Stark wrote:
>
> I've uploaded a quick hack to store numerics in < 8 bytes when possible.
>
> http://community.enterprisedb.com/numeri
Hi all
Here's the current version of the enums patch. Not much change from last
time, the only thought-inducing stuff was fixing up some macros that
changed with the VARLENA changes, and adding a regression test to do
basic checking of RI behavior, after the discussions that we had
recently o
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
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:
> Jeremy Drake wrote:
>> On Thu, 22 Mar 2007, Tom Lane wrote:
>>> AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
>>> datatypes) is lack of obvious usefulness.
>> If you are asking why I have reason to convert text * to a Datum in c
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jeremy Drake wrote:
> >> On Thu, 22 Mar 2007, Tom Lane wrote:
> >>> AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
> >>> datatypes) is lack of obvious usefulness.
>
> >> If you are asking why I have reason to
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
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
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
On Mon, 26 Mar 2007, Bruce Momjian wrote:
> Tom Lane wrote:
> > Or were you speaking to the question of whether to adjust the regexp
> > patch to conform more nearly to the coding practices found elsewhere?
> > I agree with that, but I thought there was already a submitted patch
> > for it.
>
> Ye
Hi,
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
and
http://archives.postgresql.org/pgsql-patches/2007-01/msg00607.php
Update includes some modification for error handling in archiver and
restoration comma
27 matches
Mail list logo