Re: [PATCHES] [pgadmin-hackers] Adminpack contrib module
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andrus > Sent: 08 May 2006 18:16 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Adminpack contrib module > > > There were no objections, so attached is an updated version of the > > adminpack, with non-version specific naming for addition to > the source > > tree. > > The entire directory in the archive should be added to > /contrib, and > > an appropriate entry added to contrib/Makefile. > > adminpack.sql.in file contains comment > > /* generic file access functions (genfile.c) */ > > However, there is no genfile.c file in this package. Well spotted - update attached. Thanks, Dave. adminpack.tar.gz Description: adminpack.tar.gz ---(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] Cleaning up multiply-defined-symbol warnings on OS X
Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout: > What it does is remove the restriction that any one program can only > use (directly or indirectly) one version of libpq at any moment. > Programs can use indirectly postgres via PAM or NSS or other such > pluggable interfaces. Currently PAM and NSS must be using the same > version of libpq as any program that might call them or everything > blows up. Symbol versioning only helps if a function's signature has changed, doesn't it? Have we ever done that? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Have configure complain about unknown options
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout: > 1. Provide an escape option they can add > 2. Package systems can usually apply patches prior to compiling, they can > always remove the offending line if they like. > 3. Try and get feedback from them now rather than wait My feedback is this: You are going to enter a world of pain. If you are worried about mistyping options, I recommend setting up a shell alias. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Cleaning up multiply-defined-symbol warnings on OS X
On Tue, May 09, 2006 at 10:19:56AM +0200, Peter Eisentraut wrote: > Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout: > > What it does is remove the restriction that any one program can only > > use (directly or indirectly) one version of libpq at any moment. > > Programs can use indirectly postgres via PAM or NSS or other such > > pluggable interfaces. Currently PAM and NSS must be using the same > > version of libpq as any program that might call them or everything > > blows up. > > Symbol versioning only helps if a function's signature has changed, doesn't > it? Have we ever done that? Depends what you mean by signature. The structures of PGconn and PGresult have changed over time, so if you you pass a PGresult allocated by libpq4 to a function in libpq3, it'll crash. Symbol versioning can serve a few purposes: 1. You can have one library supporting several ABIs simultaneously. glibc does this but that's not what we're interested in. 2. When loading a library, the linker checks both the symbol name and the symbol version. Thus, it allows two versions of the same library to co-exist in the same address space simultaneously. This is what we want. Basically, if you symbol version, a program compiled against a particular version with only call functions in that version and won't be accedently misdirected to another version that happened to be loaded first... In the example I posted earlier, say psql starts, compiled against libpq5. It does a gethostbyname() that is redirected to an NSS module originally compiled against libpq4. The linker will load libpq4 but link the actual symbols of the NSS module to libpq5. Any it can't find there it will find in libpq4. It's this splitting up that will get you. Loading this way round is unlikely to cause many problems since we don't tend to remove functions from the API so it may not link any symbols to libpq4. The more dangerous situation is if the old library gets loaded first and something uses symbols that didn't exist in the old version but do in the new version. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] Have configure complain about unknown options
On 5/9/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout: > 1. Provide an escape option they can add > 2. Package systems can usually apply patches prior to compiling, they can > always remove the offending line if they like. > 3. Try and get feedback from them now rather than wait My feedback is this: You are going to enter a world of pain. Seems that way. Especially if the non-PGAC options won't be handled automatically. Some projects have solved the problem different way - by printing out the summary of most important options at the end of configure: PostgreSQL version X.X.X OpenSSL: no Integer datatime: yes Python: yes Perl: yes So at the end of configure the user can visually confirm his expectations without needing to parse the noise from full configure output. Maybe this would be better solution. -- marko ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Have configure complain about unknown options
On Tue, May 09, 2006 at 10:37:43AM +0200, Peter Eisentraut wrote: > Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout: > > 1. Provide an escape option they can add > > 2. Package systems can usually apply patches prior to compiling, they can > > always remove the offending line if they like. > > 3. Try and get feedback from them now rather than wait > > My feedback is this: You are going to enter a world of pain. Can you explain why? Unknown options don't do anything, so having users remove them seems like a good move. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] pgstat: remove delayed destroy / pipe: socket
Yep, the pipe.c patch is unnecessary now. Pete >>> Bruce Momjian 05/07/06 3:44 am >>> Now that we know the cause of the Win32 failure (FRONTEND), we don't need the Win32 part of this patch anymore right? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: current version: [PATCHES] Patch - Have psql show current values
Bruce Momjian wrote:
I am thinking we just add another column to the \d display for sequences
showing the current value.
---
As suggested in the previous mails, I tried to use the following to
display the seq. value.
select last_value from .
However, it was not possible to display the seq. value using this.
Hence, I made a small change in the currval() function, so that it
retrieves the last_value
even if the the value is not cached.
I hope this patch will be more suitable for this issue. Pl. look at the
patch.
Thanks
Dhanaraj
*** ./src/backend/commands/sequence.c.orig Tue May 2 14:51:03 2006
--- ./src/backend/commands/sequence.c Tue May 9 13:52:38 2006
***
*** 605,610
--- 605,612
int64 result;
SeqTable elm;
Relation seqrel;
+ Form_pg_sequence seq;
+ Buffer buf;
/* open and AccessShareLock sequence */
init_sequence(relid, &elm, &seqrel);
***
*** 616,632
errmsg("permission denied for sequence %s",
RelationGetRelationName(seqrel;
! if (elm->increment == 0) /* nextval/read_info were not called */
! ereport(ERROR,
! (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
! errmsg("currval of sequence \"%s\" is not yet defined in this session",
! RelationGetRelationName(seqrel;
! result = elm->last;
! relation_close(seqrel, NoLock);
! PG_RETURN_INT64(result);
}
Datum
--- 618,641
errmsg("permission denied for sequence %s",
RelationGetRelationName(seqrel;
! if ((elm->increment != 0) ||(elm->last != elm->cached)) /* some numbers were cached */
! {
! result = elm->last;
! relation_close(seqrel, NoLock);
! PG_RETURN_INT64(result);
! }
! /* lock page' buffer and read tuple if not cached */
! seq = read_info(elm, seqrel, &buf);
! result = seq->last_value;
! UnlockReleaseBuffer(buf);
! relation_close(seqrel, NoLock);
! seqtab = elm->next;
! free(elm);
!
! PG_RETURN_INT64(result);
}
Datum
*** ./src/bin/psql/describe.c.orig Thu Apr 27 04:45:45 2006
--- ./src/bin/psql/describe.c Tue May 9 16:26:10 2006
***
*** 1480,1485
--- 1480,1488
_("table"), _("view"), _("index"), _("sequence"),
_("special"), _("Type"), _("Owner"));
+ if (showSeq && !showTables)
+ appendPQExpBuffer(&buf,",\n currval(CAST(c.relname AS pg_catalog.text)) as \"%s\"",_("value"));
+
if (showIndexes)
appendPQExpBuffer(&buf,
",\n c2.relname as \"%s\"",
No differences encountered
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Cleaning up multiply-defined-symbol warnings on OS X
Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout: > Depends what you mean by signature. The structures of PGconn and > PGresult have changed over time, so if you you pass a PGresult > allocated by libpq4 to a function in libpq3, it'll crash. Symbol versioning only affects functions (and maybe variables?) but not structs. Nothing helps in that case. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Have configure complain about unknown options
Am Dienstag, 9. Mai 2006 10:55 schrieb Martijn van Oosterhout: > Can you explain why? Unknown options don't do anything, so having users > remove them seems like a good move. Build system frameworks assume that they can pass any option and that unknown options will be ignored. This grew out of the old Cygnus GNU megatree but as you saw it is also used by package building frameworks like CDBS. In fact, if we one day separate the PLs into separate source tarballs, I'd like to set up a similar megatree system so building everything becomes easier. I don't object to having a strict mode or printing warnings or printing a summary at the end, but we are not in a position to redefine build system practice. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Cleaning up multiply-defined-symbol warnings on OS X
On Tue, May 09, 2006 at 01:50:38PM +0200, Peter Eisentraut wrote: > Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout: > > Depends what you mean by signature. The structures of PGconn and > > PGresult have changed over time, so if you you pass a PGresult > > allocated by libpq4 to a function in libpq3, it'll crash. > > Symbol versioning only affects functions (and maybe variables?) but not > structs. Nothing helps in that case. Eh? It stops a program expecting libpq4 being linked to libpq3 for any reason, so the above situation can't happen. You don't need to version any structs, only the functions using them. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] Cleaning up multiply-defined-symbol warnings on OS X
Martijn van Oosterhout writes: > Eh? It stops a program expecting libpq4 being linked to libpq3 for any > reason, so the above situation can't happen. You don't need to version > any structs, only the functions using them. If we have an existing app built against an unversioned libpq, what happens if we roll in a versioned libpq? Does it break completely? That is, is the introduction of versioning by itself an incompatible ABI break? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: current version: [PATCHES] Patch - Have psql show current values
Dhanaraj M <[EMAIL PROTECTED]> writes: > However, it was not possible to display the seq. value using this. > Hence, I made a small change in the currval() function, so that it > retrieves the last_value > even if the the value is not cached. Breaking currval()'s semantics is not an acceptable solution for this. The best, fully backward compatible solution is for psql to issue "SELECT last_value FROM " queries to get the values. This might be a bit tricky to wedge into the structure of describe.c, but I don't see any fundamental reason why it can't be done. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Encryption of .pgpass
Dear Bruce san. I may be quite persistent.:-) I seasoned the proposal method. It was very painful that the conventional connection method to this password was a plain text. Although I am simple, I desire the support. Furthermore, the relation between a field item and an environment variable is complicated. ex.) inetrt% pqpasswd -U postgres -d postgres New Password: Retype New Password: Succeeded in creation. inetrt% pqpasswd -U postgres -d postgres -l /home/saito/.pgpass hostname=localhost port=5432 dbname=postgres username=postgres password=** This 1th line is used. inetrt% cat /home/saito/.pgpass localhost:5432:postgres:postgres:postgres inetrt% psql postgres postgres Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# inetrt% rm /home/saito/.pgpass inetrt% pqpasswd -U postgres -d postgres -m New Password: Retype New Password: Succeeded in creation. inetrt% pqpasswd -U postgres -d postgres -m -l /home/saito/.pgpass.md5 hostname=localhost port=5432 dbname=postgres username=postgres password=** This 1th line is used. inetrt% cat /home/saito/.pgpass.md5 localhost:5432:postgres:postgres:md53175bce1d3201d16594cebf9d7eb3f9d inetrt% psql postgres postgres Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# inetrt% rm /home/saito/.pgpass.md5 inetrt% psql postgres postgres Password for user postgres: Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit I tried correspondence by sufix of md5 to .pgpass, in order to maintain compatibility. I wish that it is fully reviewed. Thanks. Regards, Hiroshi Saito pqpasswd_patch Description: Binary data ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Cleaning up multiply-defined-symbol warnings on OS X
On Tue, May 09, 2006 at 09:18:17AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Eh? It stops a program expecting libpq4 being linked to libpq3 for any
> > reason, so the above situation can't happen. You don't need to version
> > any structs, only the functions using them.
>
> If we have an existing app built against an unversioned libpq, what
> happens if we roll in a versioned libpq? Does it break completely?
> That is, is the introduction of versioning by itself an incompatible
> ABI break?
This is a special rules:
- If a program (like psql) requires a symbol but specifies no symbol
version, it will match against that symbol without a version, or if not
found, the symbol with the lowest version number.
So if you slide a versioned library under a program that doesn't know
about it, it will load fine because unversioned symbols match anything.
Here is a quick example of how it works:
$ cat prog.c
extern int func();
int main()
{
return func();
}
$ cat lib.c
int func()
{
return 1;
}
$ cat ver_script
VERSION_1 { global: *; };
### Create the various versions ###
$ gcc -shared lib.c -Wl,--version-script=ver_script -Wl,-soname=liblib.so -o
liblib_ver.so
$ gcc -shared lib.c -Wl,-soname=liblib.so -o liblib_nover.so
$ gcc -o prog_ver prog.c -L$PWD -llib_ver
$ gcc -o prog_nover prog.c -L$PWD -llib_nover
### Test ###
$ mkdir test
$ cp liblib_nover.so test/liblib.so
$ cp prog_nover test/prog
$ LD_LIBRARY_PATH=$PWD/test test/prog # Works (both no version)
$ cp liblib_nover.so test/liblib.so
$ cp prog_ver test/prog
$ LD_LIBRARY_PATH=$PWD/test test/prog # Doesn't work (prog with version,
lib without)
test/prog: /tmp/t/test/liblib.so: no version information available (required by
test/prog)
$ cp liblib_ver.so test/liblib.so
$ cp prog_ver test/prog
$ LD_LIBRARY_PATH=$PWD/test test/prog # Works (both with version)
$ cp liblib_ver.so test/liblib.so
$ cp prog_nover test/prog
$ LD_LIBRARY_PATH=$PWD/test test/prog # Works (prog without version, lib
with)
You can make that broken variation work too, if the version is marked
as weak, but I couldn't quickly find out how.
http://people.redhat.com/drepper/symbol-versioning
Hope this helps,
--
Martijn van Oosterhout http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to
> litigate.
signature.asc
Description: Digital signature
Re: [PATCHES] Have configure complain about unknown options
Marko Kreen wrote: > On 5/9/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > > Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout: > > > 1. Provide an escape option they can add > > > 2. Package systems can usually apply patches prior to compiling, they can > > > always remove the offending line if they like. > > > 3. Try and get feedback from them now rather than wait > > > > My feedback is this: You are going to enter a world of pain. > > Seems that way. Especially if the non-PGAC options won't be > handled automatically. > > Some projects have solved the problem different way - by printing > out the summary of most important options at the end of configure: > > PostgreSQL version X.X.X > OpenSSL: no > Integer datatime: yes > Python: yes > Perl: yes > > So at the end of configure the user can visually confirm > his expectations without needing to parse the noise > from full configure output. Maybe this would be better > solution. Seems we would be best printing out options we _didn't_ undertand at the end of the build. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://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] Encryption of .pgpass
"Hiroshi Saito" <[EMAIL PROTECTED]> writes: > I may be quite persistent.:-) > I seasoned the proposal method. It was very painful that the > conventional connection method to this password was a plain text. > Although I am simple, I desire the support. Furthermore, the relation > between a field item and an environment variable is complicated. What is the point of this? It seems to be complicating life to little purpose (except storing passwords that will fail in non-MD5 password methods --- given that people are talking about replacing MD5, that doesn't seem like a good forward-looking idea). regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Encryption of .pgpass
From: "Tom Lane" <[EMAIL PROTECTED]> > What is the point of this? It seems to be complicating life to little > purpose (except storing passwords that will fail in non-MD5 password > methods --- given that people are talking about replacing MD5, that > doesn't seem like a good forward-looking idea). Ahh, yes. It is "crypt" ,"ident" and "pam"... I do not think that "passwd" should be used primarily. Then, So, it is clear sufix of md5. It may be a narrower use. However, I have simplified that it can use as a method of hiding it. It is suggestion. Is it accepted by including "crypt"? Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Have configure complain about unknown options
On Tue, May 09, 2006 at 11:35:32AM -0400, Bruce Momjian wrote: > > So at the end of configure the user can visually confirm > > his expectations without needing to parse the noise > > from full configure output. Maybe this would be better > > solution. > > Seems we would be best printing out options we _didn't_ undertand at the > end of the build. I can live with that. It's a minor tweak... Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] cast bytea to/from bit strings
Dear Tom, I think that the inability to convert nearly binary compatible standard types one to the other is a postgresql issue. Even if it is not often useful, the point is completeness and soundness of the type provided by the core. OK, can I get some feedback from others about this patch? I think Fabien is way overstating his case here. Maybe. It's not immediately obvious that there should be a cast between bit(n) and bytea, and it's even less obvious that it should be done in a way that exposes the internal representation of bit(n) as this does. Hmmm... I think people guessed it anyway;-) Well, if there is a big/little endian issue, I agree that it is not a good idea. As I cast at the byte level, it seems to me that it should be okay. If so, I see no real harm in having an *explicit* cast allowed, which by nature may be a little destructive, as long as it is reasonnable. There's no principled reason for one bit ordering over the other, for example, nor any very clean way to handle coercions where N isn't a multiple of 8. It could be rejected instead. I think this request has more to do with a lack of adequate operators for one type or the other. If we're missing, say, bitwise logical operators for bytea, then let's add those rather than create a bogus equivalence between the types. Indeed, what triggers my development for this cast was that I needed a xor on md5 results, which can only be converted to bytea with convert. I could develop a bunch of bitwise operators for bytea, but casting to varbit where they are already available was the quickest path. -- Fabien. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] [PATCH] Improve EXPLAIN ANALYZE overhead by sampling
This was a suggestion made back in March that would dramatically reduce the overhead of EXPLAIN ANALYZE on queries that loop continuously over the same nodes. http://archives.postgresql.org/pgsql-hackers/2006-03/msg01114.php What it does behave normally for the first 50 tuples of any node, but after that it starts sampling at ever increasing intervals, the intervals controlled by an exponential function. So for a node iterating over 1 million tuples it takes around 15,000 samples. The result is that EXPLAIN ANALYZE has a much reduced effect on the total execution time. Without EXPLAIN ANALYZE: postgres=# select count(*) from generate_series(1,100); count - 100 (1 row) Time: 2303.599 ms EXPLAIN ANALYZE without patch: postgres=# explain analyze select count(*) from generate_series(1,100); QUERY PLAN Aggregate (cost=15.00..15.01 rows=1 width=0) (actual time=8022.070..8022.073 rows=1 loops=1) -> Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=0) (actual time=1381.762..4873.369 rows=100 loops=1) Total runtime: 8042.472 ms (3 rows) Time: 8043.401 ms EXPLAIN ANALYZE with patch: postgres=# explain analyze select count(*) from generate_series(1,100); QUERY PLAN Aggregate (cost=15.00..15.01 rows=1 width=0) (actual time=2469.491..2469.494 rows=1 loops=1) -> Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=0) (actual time=1405.002..2187.417 rows=100 loops=1) Total runtime: 2496.529 ms (3 rows) Time: 2497.488 ms As you can see, the overhead goes from 5.7 seconds to 0.2 seconds. Obviously this is an extreme case, but it will probably help in a lot of other cases people have been complaining about. - To get this close it needs to get an estimate of the sampling overhead. It does this by a little calibration loop that is run once per backend. If you don't do this, you end up assuming all tuples take the same time as tuples with the overhead, resulting in nodes apparently taking longer than their parent nodes. Incidently, I measured the overhead to be about 3.6us per tuple per node on my (admittedly slightly old) machine. Note that the resulting times still include the overhead actually incurred, I didn't filter it out. I want the times to remain reflecting reality as closely as possible. - I also removed InstrStopNodeMulti and made InstrStopNode take a tuple count parameter instead. This is much clearer all round. - I also didn't make it optional. I'm unsure about whether it should be optional or not, given the number of cases where it will make a difference to be very few. - The tuple counter for sampling restarts every loop. Thus a node that is called repeatedly only returning one value each time will still measure every tuple, though its parent node won't. We'll need some field testing to see if that remains a significant effect. - I don't let the user know anywhere how many samples it took. Is this something users should care about? Any comments? -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. Index: src/backend/commands/trigger.c === RCS file: /projects/cvsroot/pgsql/src/backend/commands/trigger.c,v retrieving revision 1.201 diff -c -r1.201 trigger.c *** src/backend/commands/trigger.c 27 Apr 2006 00:33:41 - 1.201 --- src/backend/commands/trigger.c 9 May 2006 20:35:07 - *** *** 1306,1312 * one "tuple returned" (really the number of firings). */ if (instr) ! InstrStopNode(instr + tgindx, true); return (HeapTuple) DatumGetPointer(result); } --- 1306,1312 * one "tuple returned" (really the number of firings). */ if (instr) ! InstrStopNode(instr + tgindx, 1); return (HeapTuple) DatumGetPointer(result); } *** *** 2154,2160 * one "tuple returned" (really the number of firings). */ if (instr) ! InstrStopNode(instr + tgindx, true); } --- 2154,2160 * one "tuple returned" (really the number of firings). */ if (instr) ! InstrStopNode(instr + tgindx, 1); } Index: src/backend/executor/execProcnode.c === RCS file: /projects/cvsroot/pg
Re: [PATCHES] [PATCH] Improve EXPLAIN ANALYZE overhead by sampling
On Tue, 2006-05-09 at 22:37 +0200, Martijn van Oosterhout wrote: > This was a suggestion made back in March that would dramatically reduce > the overhead of EXPLAIN ANALYZE on queries that loop continuously over > the same nodes. > > http://archives.postgresql.org/pgsql-hackers/2006-03/msg01114.php > > As you can see, the overhead goes from 5.7 seconds to 0.2 seconds. > Obviously this is an extreme case, but it will probably help in a lot > of other cases people have been complaining about. This seems much more useful behaviour than currently. Running an EXPLAIN ANALYZE for large queries can be a real pain, especially on a production box which is in live use - so tuning a test tool has a meaningful effect on other users performance too. There's a lot of thought gone in here, so I'd vote yes, though without having done a detailed code review. -- 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] [PATCH] Improve EXPLAIN ANALYZE overhead by sampling
> - To get this close it needs to get an estimate of the sampling overhead. > It does this by a little calibration loop that is run once per backend. > If you don't do this, you end up assuming all tuples take the same time > as tuples with the overhead, resulting in nodes apparently taking > longer than their parent nodes. Incidently, I measured the overhead to > be about 3.6us per tuple per node on my (admittedly slightly old) > machine. Could this be deferred until the first explain analyze? So that we aren't paying the overhead of the calibration in all backends, even the ones that won't be explaining? -rocco ---(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] Improve EXPLAIN ANALYZE overhead by sampling
On Tue, May 09, 2006 at 05:16:57PM -0400, Rocco Altier wrote: > > - To get this close it needs to get an estimate of the sampling > > overhead. It does this by a little calibration loop that is run > > once per backend. If you don't do this, you end up assuming all > > tuples take the same time as tuples with the overhead, resulting in > > nodes apparently taking longer than their parent nodes. Incidently, > > I measured the overhead to be about 3.6us per tuple per node on my > > (admittedly slightly old) machine. > > Could this be deferred until the first explain analyze? So that we > aren't paying the overhead of the calibration in all backends, even the > ones that won't be explaining? If you look it's only done on the first call to InstrAlloc() which should be when you run EXPLAIN ANALYZE for the first time. In any case, the calibration is limited to half a millisecond (that's 500 microseconds), and it'll be a less on fast machines. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
