[PATCHES] Packed Varlena Update (v21)
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. varvarlena-21.patch.gz Description: Binary data -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [pgsql-patches] [HACKERS] less privileged pl install
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) behavior you had. Also you missed updating pg_dump. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 catcache entries. This might have some other advantages (I think most of the current CopySnapshot operations could be replaced by refcount increments) Seems like we should do this for many reasons, whether or not this is one of them. I seem to have butted heads and lost more than once with not being able to tell which Snapshots exist. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 your xid is old? Hmm, yes. How often do we have an LRT that consists of multiple statements of significant duration? Not often, I'd wager. How much does it cost to optimise for this case? Did Heikki's patch to move the xmin forward during VACUUM get rejected? That seems like it has a much wider use case. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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 acceptable --- there is nothing in the standard that requires such behavior, and I dislike the wide-ranging kluges you introduced to support it. Please get rid of that and put the behavior back into ordinary DEFAULT-substitution where it belongs. - to minimize runtime impact of checking whether an index references the IDENTITY column and skipping it in the first step in ExecInsertIndexTuples(), I introduced a new attribute in the pg_index catalog. This is likewise unreasonably complex and fragile ... but it goes away anyway if you remove the above, no? The patch appears to believe that OVERRIDING SYSTEM VALUE should be restricted to the table owner, but I don't actually see any support for that in the SQL2003 spec ... where did you get that from? I'm pretty dubious about the kluges in aclchk.c to automatically grant/revoke on dependent sequences --- particularly the revoke part. The problem with that is that it breaks if the same sequence is being used to feed multiple tables. User-facing errors need to be ereport() not elog() so that they can be translated and have appropriate SQLSTATEs reported. elog is only for internal errors. One other thought is that the field names based on force_default seemed confusing. I'd suggest that maybe generated would be a better name choice. Please fix and resubmit. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 between your xmin is old and your xid is old? Hmm, yes. How often do we have an LRT that consists of multiple statements of significant duration? Not often, I'd wager. How much does it cost to optimise for this case? Zero cost. It involves just tracking if there are any old snapshots, and if not, update the proc xmin rather than skipping the asignment, like we do now. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 for many simple cases (eg, all single-statement transactions) the benefit will indeed be zero. We need some serious consideration of the costs and benefits, not airy dismissals. I had originally thought that we could avoid CopySnapshot copying, which might buy back more than enough to cover the cost of tracking reference counts ... but in a quick look yesterday it seemed that the high-use code paths would still need a copy, because they are always copying off the static variables filled by GetTransactionSnapshot. Changing that would come with a tremendous memory penalty, or else a time penalty to scan the ProcArray twice to see how big the arrays need to be. [ thinks a bit... ] The other way we might possibly tackle that is to avoid copying by the expedient of just using those static snapshot variables in-place. SerializableSnapshot surely need never be copied since it remains unchanged till end of xact, and no use of the snap will survive longer than that. In simple cases LatestSnapshot is not overwritten until the prior value is no longer needed, either. If we could arrange to copy it only when setting up a cursor, or other long-lived usage, we'd be ahead of the game. But I'd certainly want a management layer in there to ensure that we don't overwrite a value that *is* still in use, and offhand I'm not sure what that layer would need to look like. Possibly some sort of double indirection so that callers would have a Snapshot pointer that remained valid after we'd copied off arrays that need to be updated? We already do have double indirection in the form of the Snapshot and xip[] pointers ... maybe attach refcounts to the xip arrays not the Snapshots per se? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 that. Is that now possible to do cleanly? I am having trouble getting this to work in the attached patch. --- Tom Lane wrote: 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 for many simple cases (eg, all single-statement transactions) the benefit will indeed be zero. We need some serious consideration of the costs and benefits, not airy dismissals. I had originally thought that we could avoid CopySnapshot copying, which might buy back more than enough to cover the cost of tracking reference counts ... but in a quick look yesterday it seemed that the high-use code paths would still need a copy, because they are always copying off the static variables filled by GetTransactionSnapshot. Changing that would come with a tremendous memory penalty, or else a time penalty to scan the ProcArray twice to see how big the arrays need to be. [ thinks a bit... ] The other way we might possibly tackle that is to avoid copying by the expedient of just using those static snapshot variables in-place. SerializableSnapshot surely need never be copied since it remains unchanged till end of xact, and no use of the snap will survive longer than that. In simple cases LatestSnapshot is not overwritten until the prior value is no longer needed, either. If we could arrange to copy it only when setting up a cursor, or other long-lived usage, we'd be ahead of the game. But I'd certainly want a management layer in there to ensure that we don't overwrite a value that *is* still in use, and offhand I'm not sure what that layer would need to look like. Possibly some sort of double indirection so that callers would have a Snapshot pointer that remained valid after we'd copied off arrays that need to be updated? We already do have double indirection in the form of the Snapshot and xip[] pointers ... maybe attach refcounts to the xip arrays not the Snapshots per se? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/backend/catalog/index.c === RCS file: /cvsroot/pgsql/src/backend/catalog/index.c,v retrieving revision 1.281 diff -c -c -r1.281 index.c *** src/backend/catalog/index.c 25 Mar 2007 19:45:14 - 1.281 --- src/backend/catalog/index.c 26 Mar 2007 21:06:30 - *** *** 1358,1364 ExprContext *econtext; Snapshot snapshot; TransactionId OldestXmin; ! /* * sanity checks */ --- 1358,1364 ExprContext *econtext; Snapshot snapshot; TransactionId OldestXmin; ! /* * sanity checks */ *** *** 1555,1561 ExecDropSingleTupleTableSlot(slot); FreeExecutorState(estate); ! /* These may have been pointing to the now-gone estate */ indexInfo-ii_ExpressionsState = NIL; indexInfo-ii_PredicateState = NIL; --- 1555,1563 ExecDropSingleTupleTableSlot(slot); FreeExecutorState(estate); ! if (snapshot != SnapshotNow) ! FreeSnapshot(snapshot); ! /* These may have been pointing to the now-gone estate */ indexInfo-ii_ExpressionsState = NIL; indexInfo-ii_PredicateState = NIL; Index: src/backend/commands/cluster.c === RCS file: /cvsroot/pgsql/src/backend/commands/cluster.c,v retrieving revision 1.157 diff -c -c -r1.157 cluster.c *** src/backend/commands/cluster.c 13 Mar 2007 00:33:39 - 1.157 --- src/backend/commands/cluster.c 26 Mar 2007 21:06:30 - *** *** 204,209 --- 204,210 /* Start a new transaction for each relation. */ StartTransactionCommand(); /* functions in indexes may want a snapshot set */ + FreeSnapshot(ActiveSnapshot); ActiveSnapshot = CopySnapshot(GetTransactionSnapshot()); cluster_rel(rvtc, true); CommitTransactionCommand(); Index: src/backend/commands/indexcmds.c
Re: [PATCHES] [pgsql-patches] [HACKERS] less privileged pl install
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, rather than the rather strange (and undocumented) behavior you had. The reason I did it like that was this email from you: http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php Also you missed updating pg_dump. Indeed. Now, all I need is the 'tsearch2 in core' patch to go in, and 8.3 will solve almost all of my problems :) Then I just need to nag my hosting provider to upgrade once it is released. I have been refraining from nagging about them still running 8.1.3 in anticipation of this ;) -- Five is a sufficiently close approximation to infinity. -- Robert Firth ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 tracking anything more complicated than that. Is that now possible to do cleanly? I am having trouble getting this to work in the attached patch. No kidding. Even if you get it to pass the regression tests, it'll be a constant source of bugs. IMHO the *only* way to do this reliably is to have a centralized reference-count management module. I've been thinking more about the avoid-copy idea and I think it will indeed work, and be simpler than what we have now, to boot. Ideas: * There is only one (pair of) statically allocated, max-size XID arrays for GetSnapshotData to read into. When we want to acquire a new snap from GetSnapshotData, we palloc a new SnapshotData struct (and no more), make it point at the statically allocated arrays, fill and return it. * There can be at most one SnapshotData struct using the statically allocated arrays. We remember its address in a static variable (which goes NULL when there is no such struct). If we have to acquire a new snapshot before the old one's refcount has gone to zero, then at that time we palloc arrays just big enough for the old one, copy the static data to there, insert the palloc'd array pointers into the old one, and clear the static variable (or more likely, immediately set it to point to the new one). * All the current CopySnapshot operations are replaced by refcount increments. We need explicit refcount-decrement calls added, and ResourceOwner support to make sure they happen. (I'm imagining that snapshots will now live in a dedicated context, so they don't go away implicitly but need explicit release operations. The ResourceOwner infrastructure will help us find any missed releases.) * Decrementing the refcount on a SnapshotData pfree's it if the refcount has gone to zero, and also clears the aforementioned static pointer variable if it happens to point at that selfsame struct. Note that for a serializable transaction, or a simple read-committed transaction that doesn't use more than one snap at a time, this will always happen and so there will be zero copying cost. * In this scheme the distinction between SerializableSnapshot and LatestSnapshot vanishes, at least at the level of memory management. Probably SerializableSnapshot would translate into a refcount held by xact.c or some other upper-level module. * We keep all the live MVCC snapshots in a linked list managed by a snapshot cache module. We can traverse this list to determine the minimum xmin at any instant. Freeing a snap whose xmin equals the current MyProc-xmin causes us to traverse the list, determine the new backend-wide xmin, and update MyProc-xmin. Freeing the last snap causes us to reset MyProc-xmin to 0. (I'm not completely sure, but I think that we can just set MyProc-xmin in these cases, without bothering to lock the ProcArray --- any comments on that?) * GetSnapshotData no longer cares about serializable vs nonserializable snaps, either. Its rule is just if MyProc-xmin is 0, then set it. This can happen only when creating the first snap in a transaction that currently has no live snaps. * The above two rules clearly suffice to maintain the invariant MyProc-xmin is the minimum of the xmins of the live snapshots in the transaction, or zero when there are none. Which is what we want. 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 extra management logic, 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). regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [pgsql-patches] [HACKERS] less privileged pl install
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 did it like that was this email from you: http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php Yeah, but that idea predated the addition of ALTER LANGUAGE OWNER to the patch. Given that, a superuser can give away the language to someone else if he wants, and so there's no need for us to try to be fancy about guessing what he wants (which was more or less what that rule was). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 extra management logic, 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). The improvement is going to be a win for multi-statement transactions --- the only question is how often are they long-running. It does seem best to put this on the TODO for 8.4, and I will do that now. The only thing that makes it tempting to get into 8.3 is that we could advertise this release as a major space reuse release because of HOT, autovacuum on by default, multiple autovacuum processes, and, if we added it, improved VACUUM for multi-statement transactions. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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] writes: On the whole though I think we should let this idea go till 8.4; I tend to agree but for a different reason. I think it's something that will open the doors for a lot of new ideas. If we put it in CVS HEAD early in 8.4 I think (or hope at any rate) we'll think of at least a few new things we can do with the new more precise information it exposes. Just as an example, if you find you have no live snapshots can you throw out the combocid hash? Any tuple you find with a combocid that's been discarded that way must predate your current scan and therefore is deleted for you. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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? Interesting idea. If the table had triggers, it would need a snapshot, but if not, yea, that is certainly possible. --- Tom Lane [EMAIL PROTECTED] writes: On the whole though I think we should let this idea go till 8.4; I tend to agree but for a different reason. I think it's something that will open the doors for a lot of new ideas. If we put it in CVS HEAD early in 8.4 I think (or hope at any rate) we'll think of at least a few new things we can do with the new more precise information it exposes. Just as an example, if you find you have no live snapshots can you throw out the combocid hash? Any tuple you find with a combocid that's been discarded that way must predate your current scan and therefore is deleted for you. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] patch adding new regexp functions
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 returns --- and at that point PG_RETURN_TEXT_P is the thing to use. Do you have a counterexample, or does this just suggest that the regexp function patch needs some refactoring? If you are asking why I have reason to convert text * to a Datum in cases other than PG_RETURN_TEXT_P, it is used for calling text_substr functions using DirectFunctionCallN. BTW, this usage of text_substr using PointerGetDatum was copied from the pre-existing textregexsubstr function. Is there a follup patch based on this discussion? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Numeric patch to add special-case representations for 8 bytes
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/numeric-hack-1.patch This is a bit of a kludge since it doesn't actually provide any interface for external clients of the numeric module to parse the resulting data. Ie, the macros in numeric.h will return garbage. But I'm not entirely convinced that matters. It's not like those macros were really useful to any other modules anyways since there was no way to extract the actual digits. The patch is also slightly unsatisfactory because as I discovered numbers like 1.1 are stored as two digits currently. But it does work and it does save a substantial amount of space for integers. postgres=# select n,pg_column_size(n) from n; n | pg_column_size --+ 1 | 2 11 | 2 101 | 2 1001 | 3 10001 | 9 11 | 9 1.1 | 9 10.1 | 9 100.1 | 9 1000.1 | 9 1.1 | 11 10.1 | 11 I had hoped to get the second batch to be 3-4 bytes. But even now note how much space is saved for integers 1. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Current enums patch
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 on the ri_trigger stuff with generic types. The actual behavior was fixed by Tom's earlier patch, so this is just a sanity check. Cheers Tom enums.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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). The improvement is going to be a win for multi-statement transactions --- the only question is how often are they long-running. 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. To make this helpful, you have to posit a lot of overlapping long-running transactions (such that the distance back to GlobalXmin might average about twice the distance back to the oldest live XID). That's not impossible but I wonder whether it's not mostly a token of bad application design. It does seem best to put this on the TODO for 8.4, and I will do that now. Agreed. Quite aside from the time needed for a reasonable implementation, we'd really need to do more performance-testing than we have time for now. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 something running a large pg_restore? Interesting idea. Indeed. Currently, COPY forcibly sets a snapshot on the off chance something will use it, but I could certainly see making that happen lazily, ie not at all in the simple case. pg_restore is probably a lost cause, at least if you are running it in single-transaction mode. I guess there'd be tradeoffs as to whether to do that or not ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] patch adding new regexp functions
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 cases other than PG_RETURN_TEXT_P, it is used for calling text_substr functions using DirectFunctionCallN. BTW, this usage of text_substr using PointerGetDatum was copied from the pre-existing textregexsubstr function. Is there a follup patch based on this discussion? Not at the moment. I suppose someone could run around and replace PointerGetDatum by (exactly-equivalent) TextPGetDatum etc, but it seems like mostly make-work. I definitely don't want to spend time on such a project for 8.3. 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. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] patch adding new regexp functions
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 convert text * to a Datum in cases other than PG_RETURN_TEXT_P, it is used for calling text_substr functions using DirectFunctionCallN. BTW, this usage of text_substr using PointerGetDatum was copied from the pre-existing textregexsubstr function. Is there a follup patch based on this discussion? Not at the moment. I suppose someone could run around and replace PointerGetDatum by (exactly-equivalent) TextPGetDatum etc, but it seems like mostly make-work. I definitely don't want to spend time on such a project for 8.3. 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. Yes, regex patch adjustment, and I have not seen a patch which makes such adjustments. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 independent of this). The improvement is going to be a win for multi-statement transactions --- the only question is how often are they long-running. 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. To make this helpful, you have to posit a lot of overlapping long-running transactions (such that the distance back to GlobalXmin might average about twice the distance back to the oldest live XID). That's not impossible but I wonder whether it's not mostly a token of bad application design. Well, my secondary addition was to start MyProc-xmin with the current xid counter, rather than your own xid. This is because your xid is already in progress and so will not be touched, so why not start with the current xid counter. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Improvement of procArray.xmin for VACUUM
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 xid. Don't tell me you seriously believe that would work. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] patch adding new regexp functions
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. Yes, regex patch adjustment, and I have not seen a patch which makes such adjustments. http://archives.postgresql.org/pgsql-patches/2007-03/msg00285.php -- Pope Goestheveezl was the shortest reigning pope in the history of the Church, reigning for two hours and six minutes on 1 April 1866. The white smoke had hardly faded into the blue of the Vatican skies before it dawned on the assembled multitudes in St. Peter's Square that his name had hilarious possibilities. The crowds fell about, helpless with laughter, singing Half a pound of tuppenny rice Half a pound of treacle That's the way the chimney smokes Pope Goestheveezl The square was finally cleared by armed carabineri with tears of laughter streaming down their faces. The event set a record for hilarious civic functions, smashing the previous record set when Baron Hans Neizant Bompzidaize was elected Landburgher of Koln in 1653. -- Mike Harding, The Armchair Anarchist's Almanac ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Full page writes improvement, code update
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 command. In the previous threads, I posted several evaluation and shown that we can keep all the full page writes needed for full XLOG crash recovery, while compressing archive log size considerably better than gzip, with less CPU consumption. I've found no further objection for this proposal but still would like to hear comments/opinions/advices. Regards; -- Koichi Suzuki pg_lesslog.tgz Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
