Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
Tom Lane wrote: I wrote: Thus, our past arguments about whether a few microseconds of delay before commit are a good idea seem moot; we do not have any portable way of implementing that, and a ten millisecond delay for commit is clearly Not Good. I've now finished running a spectrum of pgbench scenarios, and I find no case in which commit_delay = 0 is worse than commit_delay 0. Now this is just one benchmark on just one platform, but it's pretty damning... In your test cases I always see "where bid = 1" at "update branches" i.e. update branches set bbalance = bbalance + ... where bid = 1 ISTM there's no multiple COMMIT in your senario-s due to their lock conflicts. Regards, Hiroshi Inoue
Re: [HACKERS] Bug: aliasing in ORDER BY when UNIONing
On Mon, Feb 19, 2001 at 12:26:44AM -0500, Tom Lane wrote: Marko Kreen [EMAIL PROTECTED] writes: Anyway such stuff should be documented I guess. From current docs I read that it should work. Where? And ofcourse, you are right :) I was confused of result columns vs. table columns but in the ORDER BY desc there is even explicitly said result columns. Thanks. -- marko
Re: [HACKERS] beta5 ...
Quoting The Hermit Hacker [EMAIL PROTECTED]: On Sun, 18 Feb 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: things appear to have quieted off nicely ... so would like to put out a Beta5 for testing ... Unless Peter E. has some more commits up his sleeve, I think we're good to go. okay, I'll put one out Mon aft, just in case of any strays that come up tonight, or any final commits from our overseas committers ... I'm not planning on doing any until after Beta5 is out ;-) Peter thanks ;:) -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
On Sun, 18 Feb 2001, Bruce Momjian wrote: Just shoot it over to the PHP folks. Seems they are already on top if it. I don't want to work around their normal system unless necessary. I've committed an autoconf check, so PHP 4.0.5 and upwards will be compatible with existing and future PostgreSQL versions. Additionally, discussions about starting the release process for 4.0.5 have commenced. It'd be cool, if PostgreSQL and/or the C front-end would have a numeric version indicator which we could use to check for features, etc. #include libpq-fe.h #if defined(PGSQL_FE_VERSION) PGSQL_FE_VERSION 20010210 # include postgres.h #endif - Sascha
AW: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
We *do* need to support ROW_COUNT, but allowing GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c; is a lot friendlier than the standard: GET DIAGNOSTICS :a = ROW_COUNT; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; GET DIAGNOSTICS :c = OID; (not that we even support SQLCODE at this stage). Informix does: GET DIAGNOSTICS :a = ROW_COUNT, EXCEPTION 1 :b = SQLCODE; separated with comma, don't know if that is standard, but it sure looks more like the standard. Andreas
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [010219 01:37]: On Sun, 18 Feb 2001, Larry Rosenman wrote: * Bruce Momjian [EMAIL PROTECTED] [010218 22:25]: Just shoot it over to the PHP folks. Seems they are already on top if it. I don't want to work around their normal system unless necessary. Their stuff seems to sit forever. I put it in the BugDB. The problem here is that we don't plan to release 4.0.5 during the next month. I don't know the exact timeframe for the release of PostgreSQL 7.0.1, but regular releases of PostgreSQL/PHP won't compile together for at least some time. That is rather frustating for the end-user and will delay the adoption of the new PostgreSQL release. I don't believe you will break if that patch is applied now. I don't have a 7.0 handy to compile against, but I can pull one if necessary. I believe it was an error for PHP to #include postgres.h at all. Comments from other -hackers? I have a couple of other UnixWare issues that have sort of languished... I found one report which is related to UnixWare's broken system libraries (#8441). I'll look into working around that later. If there are others, please point me into their direction. That's the one I was refering to. I submitted it when 4.0.4 came out, and it didn't even draw a comment till now Thanks! (The other one was the libtool patch which Rasmus did commit). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] WAL and commit_delay
On Sun, 18 Feb 2001, Tom Lane wrote:
I think that there may be a performance advantage to pre-filling the
logfile even so, assuming that file allocation info is stored in a
Berkeley/McKusik-like fashion (note: I have no idea what ext2 or
reiserfs actually do).
ext2 is a lot like [UF]FS. reiserfs is very different, but does
have similar hole semantics.
BTW, I have attached two patches which streamline log initialisation
a little. The first (xlog-sendfile.diff) adds support for Linux's
sendfile system call. FreeBSD and HP/UX have sendfile() too, but the
prototype is different. If it's interesting, someone will have to
come up with a configure test, as autoconf scares me.
The second removes a further three syscalls from the log init path.
There are a couple of things to note here:
* I don't know why link/unlink is currently preferred over
rename. POSIX offers strong guarantees on the semantics
of the latter.
* I have assumed that the close/rename/reopen stuff is only
there for the benefit of Windows users, and ifdeffed it
for everyone else.
Matthew.
--- xlog.c.old Mon Feb 19 12:35:53 2001
+++ xlog.c Mon Feb 19 13:05:23 2001
@@ -24,6 +24,10 @@
#include locale.h
#endif
+#ifdef _HAVE_LINUX_SENDFILE
+#include sys/sendfile.h
+#endif
+
#include "access/transam.h"
#include "access/xact.h"
#include "catalog/catversion.h"
@@ -962,6 +966,24 @@
elog(STOP, "InitCreate(logfile %u seg %u) failed: %m",
logId, logSeg);
+#ifdef _HAVE_LINUX_SENDFILE
+ {
+ static int zfd = -1;
+ ssize_t len;
+
+ if (zfd 0) {
+ zfd = BasicOpenFile("/dev/zero", O_RDONLY, 0);
+ if (zfd 0)
+ elog(STOP, "Can't open /dev/zero: %m");
+ }
+ len = sendfile(fd, zfd, NULL, XLogSegSize);
+ if (len 0)
+ /* XXX - header support sendfile, but kernel doesn't? Fall
+back */
+ elog(STOP, "sendfile failed: %m");
+ if (len XLogSegSize)
+ elog(STOP, "short read on sendfile: %m");
+ }
+#else
if (lseek(fd, XLogSegSize - 1, SEEK_SET) != (off_t) (XLogSegSize - 1))
elog(STOP, "lseek(logfile %u seg %u) failed: %m",
logId, logSeg);
@@ -969,6 +991,7 @@
if (write(fd, "", 1) != 1)
elog(STOP, "write(logfile %u seg %u) failed: %m",
logId, logSeg);
+#endif
if (pg_fsync(fd) != 0)
elog(STOP, "fsync(logfile %u seg %u) failed: %m",
--- xlog.c.sf Mon Feb 19 13:10:38 2001
+++ xlog.c Mon Feb 19 13:13:55 2001
@@ -1001,22 +1001,20 @@
elog(STOP, "lseek(logfile %u seg %u off %u) failed: %m",
log, seg, 0);
+#ifndefWIN32
close(fd);
+#endif
-#ifndef __BEOS__
- if (link(tpath, path) 0)
-#else
if (rename(tpath, path) 0)
-#endif
elog(STOP, "InitRelink(logfile %u seg %u) failed: %m",
logId, logSeg);
- unlink(tpath);
-
+#ifndefWIN32
fd = BasicOpenFile(path, O_RDWR | PG_BINARY, S_IRUSR | S_IWUSR);
if (fd 0)
elog(STOP, "InitReopen(logfile %u seg %u) failed: %m",
logId, logSeg);
+#endif
return (fd);
}
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
I don't believe you will break if that patch is applied now. InvalidOid is not defined otherwise. - Sascha
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [010219 07:42]: I don't believe you will break if that patch is applied now. InvalidOid is not defined otherwise. aha. Ok. PG-Hackers: Can we include a Dummy or #warning postgres.h in 7.1? I.E.: #ifndef _POSTGRES_H #define _POSTGRES_H #warning Client Code should not include postgres.h #endif - Sascha -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
On Mon, 19 Feb 2001, Larry Rosenman wrote: * Sascha Schumann [EMAIL PROTECTED] [010219 07:42]: I don't believe you will break if that patch is applied now. InvalidOid is not defined otherwise. aha. Ok. PG-Hackers: Can we include a Dummy or #warning postgres.h in 7.1? #warning is not portable. As I've mentioned earlier, we already have addressed this issue. If you want to give it a test, please check out http://snaps.php.net/ - Sascha
Re: [HACKERS] WAL and commit_delay
On Mon, 19 Feb 2001, Matthew Kirkwood wrote: BTW, I have attached two patches which streamline log initialisation a little. The first (xlog-sendfile.diff) adds support for Linux's sendfile system call. Whoops, don't use this. It looks like Linux won't sendfile() from /dev/zero. I'll endeavour to get this fixed, but it looks like it'll be rather harder to use sendfile for this. Bah. Matthew.
Re: AW: [HACKERS] Re: beta5 ...
At least on AIX it looks like the select with 0 timeout is a noop, and does not yield the processor. There was discussion, that other OS's (BSD) also does an immediate return in case of 0 timeout. Minimum select(2) delay is 1 msec on AIX (tested with Tom's test.c). So, what was the case against using yield (2) ? BSDi doesn't have yield(). It does have sched_yield(), but that controls threads: force the current pthread to be rescheduled so there doesn't seem to be any portable way to do this. Sleeps of zero do no kernel call, and sleeps 0 sleep for a minimum of one tick. If you really want a near-zero sleep, you need to do a no-op kernel call, like umask(), but doing a simple kernel call usually is not enough because kernels usually favor the last-running process because of the CPU cache. We need a "try to schedule someone else if they are ready to run, if not, return right away" call. I think ultimately, we need the type of near-committers feedback, but not for 7.1. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Bruce Momjian [EMAIL PROTECTED] [010218 22:25]: Just shoot it over to the PHP folks. Seems they are already on top if it. I don't want to work around their normal system unless necessary. Their stuff seems to sit forever. I put it in the BugDB. I have a couple of other UnixWare issues that have sort of languished... I am sorry to hear that. Thies is supposedly working on PostgreSQL items. Can you contact him directly? He is "Thies C. Arntzen" [EMAIL PROTECTED]. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] floating point representation
Hiroshi Inoue writes: The 7.1-release seems near. May I provide the followings ? SET FLOAT4_PRECISION TO .. SET FLOAT8_PRECISION TO .. I'd prefer names that go with the SQL type names: REAL_FORMAT DOUBLE_PRECISION_FORMAT Seems a bit tacky, but a lot of work has been put in to make these names more prominent. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] floating point representation
Bruce Momjian [EMAIL PROTECTED] writes: Added to TODO: * Add SET FLOAT4_PRECISION and SET FLOAT8_PRECISION using printf args foo_PRECISION is not the right name if these variables will contain printf format strings. Perhaps foo_FORMAT? Anyone have a better idea? After further thought I think that we ought to standardize on %.6g and %.15g even if the local float.h offers slightly different values of FLT_DIG and DBL_DIG. IEEE or near-IEEE float math is so close to universal that I don't think it's worth worrying about the possibility that different precisions would be more appropriate for some platforms. Furthermore, having cross-platform consistency of display format seems more useful than not. Something else we should perhaps think about, though we are very late in beta: once these variables exist, we could have the geometry regress test set them to suppress a couple of digits, and eliminate most if not all of the need for platform-specific geometry results. Doing this would be a no-brainer at any other time in the development cycle, but right now I am worried about whether we'd be able to reconfirm regress results on all the currently-supported platforms before release. Comments? regards, tom lane
AW: AW: [HACKERS] Re: beta5 ...
So, what was the case against using yield (2) ? $ man 2 yield No entry for yield in section 2 of the manual. Lack of portability :-( I can't beleive that AIX finally has a convenience function that is missing in mainstream unix :-) $man 2 yield Purpose Yields the processor to processes with higher priorities. Description The yield subroutine forces the current running process or thread to relinquish use of the processor. If the run queue is empty when the yield subroutine is called, the calling process or kernel thread is immediately rescheduled. If the calling process has multiple threads, only the calling thread is affected. The process or thread resumes execution after all threads of equal or greater priority are scheduled to run. Andreas
Re: AW: [HACKERS] Re: beta5 ...
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: So, what was the case against using yield (2) ? $ man 2 yield No entry for yield in section 2 of the manual. Lack of portability :-( regards, tom lane
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Sascha Schumann [EMAIL PROTECTED] writes: It'd be cool, if PostgreSQL and/or the C front-end would have a numeric version indicator which we could use to check for features, etc. #include libpq-fe.h #if defined(PGSQL_FE_VERSION) PGSQL_FE_VERSION 20010210 # include postgres.h #endif AFAIK there is no need for you to be including postgres.h in *any* Postgres release --- it's supposed to be an internal header file, not something that client applications need. Try it with just #include libpq-fe.h regards, tom lane
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Sascha Schumann [EMAIL PROTECTED] writes: I don't believe you will break if that patch is applied now. InvalidOid is not defined otherwise. Oh, is that the problem? Okay, do this: #include libpq-fe.h #ifndef InvalidOid #define InvalidOid ((Oid) 0) #endif I knew there was a reason I'd moved InvalidOid into postgres_ext.h ;-) regards, tom lane
Re: [HACKERS] WAL and commit_delay
Matthew Kirkwood [EMAIL PROTECTED] writes: BTW, I have attached two patches which streamline log initialisation a little. The first (xlog-sendfile.diff) adds support for Linux's sendfile system call. FreeBSD and HP/UX have sendfile() too, but the prototype is different. If it's interesting, someone will have to come up with a configure test, as autoconf scares me. I think we don't want to mess with something as unportable as that at this late stage of the release cycle (quite aside from your later note that it doesn't work ;-)). The second removes a further three syscalls from the log init path. There are a couple of things to note here: * I don't know why link/unlink is currently preferred over rename. POSIX offers strong guarantees on the semantics of the latter. * I have assumed that the close/rename/reopen stuff is only there for the benefit of Windows users, and ifdeffed it for everyone else. The reason for avoiding rename() is that the POSIX guarantees are the wrong ones: specifically, rename promises to overwrite an existing destination, which is exactly what we *don't* want. In theory two backends cannot be executing this code in parallel, but if they were, we would not want to destroy a logfile that perhaps already contains WAL entries by the time we finish preparing our own logfile. link() will fail if the destination name exists, which is a lot safer. I'm not sure about the close/reopen stuff; I agree it looks unnecessary. But this function is going to be so I/O bound (particularly now that it fills the file) that two more kernel calls are insignificant. regards, tom lane
Re: [HACKERS] floating point representation
Peter Eisentraut [EMAIL PROTECTED] writes: Or must we postpone to fix it ? Actually, you're going to have to recode the float*in() functions, using scanf, and scanf's formats are not always equivalent to printf's. Hmm... that wouldn't matter, except for this %a format. Maybe we'd better not try to make this happen in the waning days of the 7.1 cycle. And what about the geometry types that are based on floats? They should track the float8 format, certainly. regards, tom lane
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
AFAIK there is no need for you to be including postgres.h in *any* Postgres release --- it's supposed to be an internal header file, not something that client applications need. Try it with just /home/sas/src/php4/ext/pgsql/pgsql.c: In function `php_if_pg_getlastoid': /home/sas/src/php4/ext/pgsql/pgsql.c:1260: `InvalidOid' undeclared (first use in this function) /home/sas/src/php4/ext/pgsql/pgsql.c:1260: (Each undeclared identifier is reported only once /home/sas/src/php4/ext/pgsql/pgsql.c:1260: for each function it appears in.) InvalidOid is used to check the return value of PQoidValue(). src/interfaces/libpq/fe-exec.c:PQoidValue() can return InvalidOid, so this appears like a legitimate use to me. Feel free to correct me though, I have not used the C fe before. - Sascha
Re: [HACKERS] floating point representation
Peter Eisentraut [EMAIL PROTECTED] writes: Actually, you're going to have to recode the float*in() functions, using scanf, and scanf's formats are not always equivalent to printf's. Further thought: one answer to this is to institute four SET variables, two for output and two for input; perhaps FLOAT8_FORMAT, FLOAT8_IN_FORMAT, and similarly for FLOAT4. The input formats would normally just be "%lg" and "%g" but could be changed for special cases (like reading table dumps prepared with %a output format). However, it's becoming quite clear to me that this feature needs more thought than first appeared. Accordingly, I now vote that we not try to fit it into 7.1, but do it in a more considered fashion for 7.2. regards, tom lane
Re: [HACKERS] floating point representation
Hiroshi Inoue writes: The 7.1-release seems near. May I provide the followings ? SET FLOAT4_PRECISION TO .. SET FLOAT8_PRECISION TO .. I'd prefer names that go with the SQL type names: REAL_FORMAT DOUBLE_PRECISION_FORMAT Seems a bit tacky, but a lot of work has been put in to make these names more prominent. TODO updated: * Add SET REAL_FORMAT and SET DOUBLE_PRECISION_FORMAT using printf args -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Philip Warner [EMAIL PROTECTED] writes: Unfortunately, I don't have an awful lot of free time at the moment, so I won't be able to look at this for at *least* as week. It looks like a pretty straightforward change; I'll try to get it done today. regards, tom lane
Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
Hiroshi Inoue [EMAIL PROTECTED] writes: In your test cases I always see "where bid = 1" at "update branches" i.e. update branches set bbalance = bbalance + ... where bid = 1 ISTM there's no multiple COMMIT in your senario-s due to their lock conflicts. Hmm. It looks like using a 'scaling factor' larger than 1 is necessary to spread out the updates of "branches". AFAIR, the people who reported runs with scaling factors 1 got pretty much the same results though. regards, tom lane
Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
I did not realize how much WAL improved performance when using fsync. "Schmidt, Peter" [EMAIL PROTECTED] writes: So, is it OK to use commit_delay=0? Certainly. In fact, I think that's about to become the default ;-) I agree with Tom. I did some benchmarking tests using pgbench for a computer magazine in Japan. I got a almost equal or better result for 7.1 than 7.0.3 if commit_delay=0. See included png file. -- Tatsuo Ishii [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Well, this clearly is a release-stopper because we don't want to release a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by someone. I have added it to the open items list. Done. I ended up using RESULT_OID for the keyword that wasn't specified by SQL99, after I realized that it actually *is* a keyword in the plpgsql grammar, and therefore had better not conflict with any plain identifiers that a user might want to use. Both RESULT and OID look mighty dangerous from that perspective. regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Well, this clearly is a release-stopper because we don't want to release a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by someone. I have added it to the open items list. Done. I ended up using RESULT_OID for the keyword that wasn't specified by SQL99, after I realized that it actually *is* a keyword in the plpgsql grammar, and therefore had better not conflict with any plain identifiers that a user might want to use. Both RESULT and OID look mighty dangerous from that perspective. Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- LAZY VACUUM (Vadim) visibility of joined columns in JOIN clauses Stuck btree spinlocks Documentation Changes - ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Philip Warner wrote: P.S. Is Jan around? He's been very quiet recently... He is, just a little quiet. I can live with it either way. The main problem, as said, is that we need to allow some keywords as identifiers in PL/pgSQL like in the main parser. Actually we added RESULT as a reserved word, what's a likely variable name inside of functions. So I think we have something to do anyway. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: Hmm, that's definitely what SQL99 uses for the syntax. I wonder where Jan got the SELECT INTO syntax --- did he borrow it from Oracle? Sadly, we made it up. Ah so. Well, friendliness aside, I'd go with the spec's syntax. We *do* need to support ROW_COUNT, but allowing GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c; is a lot friendlier than the standard: GET DIAGNOSTICS :a = ROW_COUNT; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; GET DIAGNOSTICS :c = OID; It looks to me like SQL99 allows GET DIAGNOSTICS :a = ROW_COUNT, :b = OID, ...; I like this one - except for the OID which should IMHO read INSERTED_OID. P.S. Is Jan around? He's been very quiet recently... He's still engaged in moving from Germany to Norfolk, VA. I think his net-access is somewhat erratic :-( Actually it's more the "custody for my children" thing than the movement itself. For the net-access: my mother's appartment has a phone line, so I can use my 33K6 modem for dialup - that's all. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; May I suggest that this is the wrong syntax? It should be GET DIAGNOSTICS variable = ROW_COUNT; See SQL99 part 2, clause 19.1. Hmm, that's definitely what SQL99 uses for the syntax. I wonder where Jan got the SELECT INTO syntax --- did he borrow it from Oracle? Anyone have an Oracle manual to check? Got it as a patch from - um - forgotten. Didn't new that there is something in the SQL99. I'd be more inclined to follow the spec than Oracle, anyway. But if we're going to change it, we'd better do so before 7.1 release, else we'll have a backwards-compatibility problem. Agreed. We'd need to come up with a name for the inserted-OID result, since that's not one of the spec-listed items. I'd suggest just GET DIAGNOSTICS variable = OID; which seems unlikely to conflict with any future spec extension. But maybe someone has a better idea. The problem here is that the PL/pgSQL parser doesn't have the mechanisms for enabling keywords as identifiers, the main parser has. So using an existing type name might cause some trouble. What about INSERTED_OID? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [HACKERS] Re: WAL and commit_delay
Tom Lane wrote: Adriaan Joubert [EMAIL PROTECTED] writes: fdatasync() is available on Tru64 and according to the man-page behaves as Tom expects. So it should be a win for us. Careful ... HPUX's man page also claims that fdatasync does something useful, but it doesn't. I'd recommend an experiment. Does today's snapshot run any faster for you (without -F) than before? IIRC your HPUX manpage states that fdatasync() updates only required information to find back the data. It sounded to me that HPUX distinguishes between irrelevant inode info (like modtime) and important things (like blocks). But maybe I'm confused by HP and they can still tell me an X for an U. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? I think both of those are actually done. Vadim might want to tweak the timeouts I selected for buffer spinlocks, but that's easily done if he does. regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Philip Warner wrote: Unfortunately, I don't have an awful lot of free time at the moment, so I won't be able to look at this for at *least* as week. I'll do it as soon as we decided about the final syntax and keywords. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? I think both of those are actually done. Vadim might want to tweak the timeouts I selected for buffer spinlocks, but that's easily done if he does. OK, I have removed these items. Doesn't look like much left. Let me move Lazy Vacuum to TODO, and remove ODBC. I will keep the web page in case we need to add some later. Thanks folks for clearing these items. --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- LAZY VACUUM (Vadim) Documentation Changes - ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? I think both of those are actually done. Vadim might want to tweak the timeouts I selected for buffer spinlocks, but that's easily done if he does. Great, so you already have it using spinlocks, but using timeouts, and it will not die under heavy load. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Performance-improvement idea: shortcircuit unique-index checks
Over the weekend I noticed that Tatsuo's pgbench benchmark seems to spend an awful lot of its time down inside _bt_check_unique. This happens because with table declarations like create table accounts(aid int, primary key(aid), bid int, abalance int, filler char(84)) and commands like update accounts set abalance = abalance + x where aid = y the "update" is inserting a new tuple and the index on aid wants to make sure this insertion doesn't violate the uniqueness constraint. To do that, it has to visit all active *and dead* tuples with the same aid index value, to make sure they're all deleted or being deleted by the current transaction. That's expensive if they're scattered all over the table. However, since we have not changed the aid column from its prior value, it seems like this check is wasted effort. We should be able to deduce that if the prior state of the row was OK then this one is too. I'm not quite sure how to implement this, but I wanted to toss the idea out for discussion. Probably we'd have to have some cooperation between the heap_update level (where the fact that it's an update is known, and where we'd have a chance to test for changes in particular columns) and the index access level. Maybe it's wrong for the index access level to have primary responsibility for uniqueness checks in the first place. Obviously this isn't going to happen for 7.1, but it might make a nice performance improvement for 7.2. Comments? regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Jan Wieck [EMAIL PROTECTED] writes: I like this one - except for the OID which should IMHO read INSERTED_OID. I just committed changes that make it RESULT_OID, but if you like INSERTED_OID better, we could change it... I think I like RESULT_OID because the standard uses RESULT. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Performance-improvement idea: shortcircuit unique-indexchecks
I'm not quite sure how to implement this, but I wanted to toss the idea out for discussion. Probably we'd have to have some cooperation between the heap_update level (where the fact that it's an update is known, and where we'd have a chance to test for changes in particular columns) and the index access level. Maybe it's wrong for the index access level to have primary responsibility for uniqueness checks in the first place. Obviously this isn't going to happen for 7.1, but it might make a nice performance improvement for 7.2. Seems a better solution would be to put a 'deleted' bit in the index so we would have to visit those heap tuples only once for a committed status. Similar to what we do with heap tuples so we don't have to visit pg_log repeatedly. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Performance-improvement idea: shortcircuit unique-index checks
Bruce Momjian [EMAIL PROTECTED] writes: Seems a better solution would be to put a 'deleted' bit in the index so we would have to visit those heap tuples only once for a committed status. Similar to what we do with heap tuples so we don't have to visit pg_log repeatedly. That's only a partial solution, since the index is still going to have to visit the row's existing tuple (which is, by definition, not yet committed dead). My point is that the index scanning done for uniqueness checks can be eliminated *entirely* for one pretty-common case. A deleted bit in index entries might be useful too, but I think it attacks a different set of cases. regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: I like this one - except for the OID which should IMHO read INSERTED_OID. I just committed changes that make it RESULT_OID, but if you like INSERTED_OID better, we could change it... Oh boy, at your current speed, my limited internet access seems really to become kinda problem. Before I participate in the discussion you already committed. That aint fair :-) RESULT_OID is OK, or make it ONE_OF_THE_NEW_CREATED_OIDS, because in the case of an INSERT ... SELECT it isn't the entire story either way. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [010219 10:57]: AFAIK there is no need for you to be including postgres.h in *any* Postgres release --- it's supposed to be an internal header file, not something that client applications need. Try it with just /home/sas/src/php4/ext/pgsql/pgsql.c: In function `php_if_pg_getlastoid': /home/sas/src/php4/ext/pgsql/pgsql.c:1260: `InvalidOid' undeclared (first use in this function) /home/sas/src/php4/ext/pgsql/pgsql.c:1260: (Each undeclared identifier is reported only once /home/sas/src/php4/ext/pgsql/pgsql.c:1260: for each function it appears in.) InvalidOid is used to check the return value of PQoidValue(). src/interfaces/libpq/fe-exec.c:PQoidValue() can return InvalidOid, so this appears like a legitimate use to me. Feel free to correct me though, I have not used the C fe before. I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. This is a PROBLEM. LER - Sascha -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Larry Rosenman [EMAIL PROTECTED] writes: I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. If we do that, no one will ever fix their code. Moreover, such an approach would conflict with the install-all-headers option... regards, tom lane
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] writes: I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. If we do that, no one will ever fix their code. Moreover, such an approach would conflict with the install-all-headers option... How about a BIG warning in the INSTALL doc, then? LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] Performance-improvement idea: shortcircuit unique-indexchecks
On Mon, 19 Feb 2001, Tom Lane wrote: I'm not quite sure how to implement this, but I wanted to toss the idea out for discussion. Probably we'd have to have some cooperation between the heap_update level (where the fact that it's an update is known, and where we'd have a chance to test for changes in particular columns) and the index access level. Maybe it's wrong for the index access level to have primary responsibility for uniqueness checks in the first place. Obviously this isn't going to happen for 7.1, but it might make a nice performance improvement for 7.2. Comments? This sounds like a win for alot of updates where keys don't change. Also, if work is going to be done here, it might be nice to make the unique constraint have the correct semantics for checking after statement rather than per-row when multiple rows are changed in the same statement since I'm pretty sure the standard semantics is that as long as the rows are different at the end of the statement it's okay (which is not what we do currently AFAICS). I'm really not sure what's involved in that though.
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Larry Rosenman [EMAIL PROTECTED] [010219 15:45]: * Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] writes: I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. If we do that, no one will ever fix their code. Moreover, such an approach would conflict with the install-all-headers option... How about a BIG warning in the INSTALL doc, then? AND make sure we nuke any OLD version in $(destdir)/include... Which will cause a file not found vs. compile errors based on redeclares...? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
old include files (was Re: [HACKERS] PHP 4.0.4pl1 / Beta 5)
Larry Rosenman [EMAIL PROTECTED] writes: AND make sure we nuke any OLD version in $(destdir)/include... Which will cause a file not found vs. compile errors based on redeclares...? Hm. Good point, not only for postgres.h but also for the other include files we no longer install by default. OTOH, what of people who have manually added the various spi.h sub-includes to their install directory? I do not think we should take it on ourselves to clean those out, but they could still cause cross-version errors. For the RPM installation this doesn't matter anyway (I think), but it would for non-RPM installs. regards, tom lane
[HACKERS] enable-debug considered pointless
I notice that if the platform's template doesn't set CFLAGS, then configure will give you -g in CFLAGS whether you ask for it or not (courtesy of AC_PROG_CC). The --enable-debug configure switch thus does not function as advertised. If we are going to say that --enable-debug isn't recommended for production, don't you think there should be a way to turn it off? Perhaps this means that all the template files should force a setting of CFLAGS; or else that we should not use the stock version of AC_PROG_CC. Or maybe just set CFLAGS to empty right before AC_PROG_CC? regards, tom lane
Re: old include files (was Re: [HACKERS] PHP 4.0.4pl1 / Beta 5)
Tom Lane wrote: For the RPM installation this doesn't matter anyway (I think), but it would for non-RPM installs. You would be correct, as the old version will be either overwritten during the new version's install or removed during the previous version's RPM uninstall. RPM is pretty good at cleaning the old out. Sometimes a little too good :-/. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Ordering problem with --with-includes
I find that if one specifies, say, configure --with-includes=/usr/local/include one gets compiler commands like cc -Ae -g +z -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -c -o pgtcl.o pgtcl.c because the -I commands are added to CPPFLAGS which appears before any -I commands the makefiles themselves add. This strikes me as uncool. For example, it will be impossible to compile Postgres if there are headers from an old version lurking in /usr/local/include, because those will be read instead of the ones from our source tree. How hard would it be to make the --with-includes -I directives appear after our own? The same problem arises for --with-libs, btw. regards, tom lane
Re: [HACKERS] Performance-improvement idea: shortcircuit unique-indexchecks
Bruce Momjian wrote: Bruce Momjian [EMAIL PROTECTED] writes: Yes. Let me add some TODO items: * Add deleted bit to index tuples to reduce heap access ISTM this isn't a bad idea. However note that there remains only 1 bit unused in IndexTupleData. Regards, Hiroshi Inoue
Re: [HACKERS] floating point representation
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Actually, you're going to have to recode the float*in() functions, using scanf, and scanf's formats are not always equivalent to printf's. Further thought: one answer to this is to institute four SET variables, two for output and two for input; perhaps FLOAT8_FORMAT, FLOAT8_IN_FORMAT, and similarly for FLOAT4. The input formats would normally just be "%lg" and "%g" but could be changed for special cases (like reading table dumps prepared with %a output format). From the first I don't want to change the current default output format "%." #FLT_DIG "g" (REAL) "%." #DBL_DIG "g" (DOUBLE PRECISION) for 7.1 because their changes would cause a regress test failure. However, it's becoming quite clear to me that this feature needs more thought than first appeared. Accordingly, I now vote that we not try to fit it into 7.1, but do it in a more considered fashion for 7.2. The simplest way to fix it quickly would be to not provide _IN_FORMAT and restrict _FORMAT to "%.*g" at present. Regards, Hiroshi Inoue
Re: [HACKERS] Re: [BUGS] Turkish locale bug
* Tom Lane [EMAIL PROTECTED] [010219 21:02]:
Larry Rosenman [EMAIL PROTECTED] writes:
What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390).
Right, that was what I meant about not wanting to hardwire assumptions
about ASCII.
We could instead code it as
if (isupper(ch))
ch = ch + ('a' - 'A');
what about:
if (isupper(ch) isalpha(ch))
ch = ch + ('a' - 'A');
?
or does that break somewhere?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] Re: [BUGS] Turkish locale bug
Larry Rosenman [EMAIL PROTECTED] writes:
What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390).
Right, that was what I meant about not wanting to hardwire assumptions
about ASCII.
We could instead code it as
if (isupper(ch))
ch = ch + ('a' - 'A');
which I believe will work on EBCDIC as well as ASCII. However, it still
breaks down if isupper() claims that anything besides 'A'..'Z' is
uppercase --- and the simple 'A' to 'Z' range check does *not* work in
EBCDIC.
It would be an interesting timewaster to try to get Postgres working on
an EBCDIC platform ;-). I'm sure there are a lot of ASCII dependencies
lurking in the code that would need to be snuffed out. However, that
doesn't mean that I'm eager to add another one here ...
regards, tom lane
[HACKERS] Re: Turkish locale bug
Tom Lane wrote: Sezai YILMAZ [EMAIL PROTECTED] writes: With Turkish locale it is not possible to write SQL queries in CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first are downgraded to "nsert" and Then "nsert" and "unon" does not match as SQL identifier. Ugh. snip How about thinking in the other direction is it possible for PostgreSQL to be able to recognised localised versions of SQL queries? i.e. For a Turkish locale it associates "nsert" INSERT and "unon" with UNION. Perhaps including this in the compilation stage (checking which locates are installed on a system, or maybe which locales are specified somewhere)? Not sure what this would do to performance though, as having to do extra SQL identifier matching might be a bit slow. This would have the advantage of the present SQL queries out there working. Regards and best wishes, Justin Clift Database Administrator
[HACKERS] Re: Turkish locale bug
Justin Clift [EMAIL PROTECTED] writes: How about thinking in the other direction is it possible for PostgreSQL to be able to recognised localised versions of SQL queries? i.e. For a Turkish locale it associates "ýnsert" INSERT and "unýon" with UNION. Hmm. Wouldn't that mean that if someone actually wrote ýnsert, it would be taken as matching the INSERT keyword, not as an identifier? If I understood Sezai correctly, that would surprise a Turkish user. But if this behavior is OK then you might have a good answer. regards, tom lane
Re: [HACKERS] floating point representationu
From the first I don't want to change the current default output format "%." #FLT_DIG "g" (REAL) "%." #DBL_DIG "g" (DOUBLE PRECISION) for 7.1 because their changes would cause a regress test failure. But we run regress with the proper setting, right? How does giving people the ability to change the defaults affect the regression tests? Hmm I'm afraid I'm misunderstanding your point. If the default float4(8) output format would be the same as current output format then we would have no problem with the current regress test. But there could be a choise to change default output format to have a large enough presision to distinguish float4(8). But are they going to change the default to run the regression tests? How do they change it? in ~/.psqlrc? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: floating point representation
Hmm, on looking at the code, this might mean we need some configure pushups to extract FLT_DIG and DBL_DIG and put those into the default strings. Do we support any platforms where these are not 6 15? In principle, yes. VAX does not use IEEE math (by default anyway) and has less range and more precision. Most machines nowadays use the IEEE definitions, but having at least one counterexample will help keep us honest ;) - Thomas
Re: [HACKERS] floating point representationu
Bruce Momjian wrote: From the first I don't want to change the current default output format "%." #FLT_DIG "g" (REAL) "%." #DBL_DIG "g" (DOUBLE PRECISION) for 7.1 because their changes would cause a regress test failure. But we run regress with the proper setting, right? How does giving people the ability to change the defaults affect the regression tests? Hmm I'm afraid I'm misunderstanding your point. If the default float4(8) output format would be the same as current output format then we would have no problem with the current regress test. But there could be a choise to change default output format to have a large enough presision to distinguish float4(8). But are they going to change the default to run the regression tests? How do they change it? in ~/.psqlrc? Probably there's a misunderstanding between you and I but unfortunaltely I don't understand what it is in my poor English. Anyway in my plan(current format as default) there would be no problem with regress test at least for 7.1. Regards, Hiroshi Inoue
Re: [HACKERS] floating point representationu
same as current output format then we would have no problem with the current regress test. But there could be a choise to change default output format to have a large enough presision to distinguish float4(8). But are they going to change the default to run the regression tests? How do they change it? in ~/.psqlrc? Probably there's a misunderstanding between you and I but unfortunaltely I don't understand what it is in my poor English. Anyway in my plan(current format as default) there would be no problem with regress test at least for 7.1. Oh, I see. I can't see any way we can make this change in 7.1. It has to be done in 7.2. You are right, changing it at this late date would be a regression disaster. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] floating point representationu
Bruce Momjian [EMAIL PROTECTED] writes: But are they going to change the default to run the regression tests? You're barking up the wrong tree, Bruce. Hiroshi specifically said that he does *not* want to change the default behavior. regards, tom lane
[HACKERS] Re: floating point representation
...right now I am worried about whether we'd be able to reconfirm regress results on all the currently-supported platforms before release. This would be an excellent topic for a full development cycle ;) Oh, I see. Never mind. I was lost. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: In your test cases I always see "where bid = 1" at "update branches" i.e. update branches set bbalance = bbalance + ... where bid = 1 ISTM there's no multiple COMMIT in your senario-s due to their lock conflicts. Hmm. It looks like using a 'scaling factor' larger than 1 is necessary to spread out the updates of "branches". AFAIR, the people who reported runs with scaling factors 1 got pretty much the same results though. People seem to believe your results are decisive and would raise your results if the evidence is required. All clients of pgbench execute the same sequence of queries. There could be various conflicts e.g. oridinary lock, buffer lock, IO spinlock ... I've been suspicious if pgbench is an (unique) appropiriate test case for evaluaing commit_delay. Regards, Hiroshi Inoue
Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
Hiroshi Inoue [EMAIL PROTECTED] writes: I've been suspicious if pgbench is an (unique) appropiriate test case for evaluaing commit_delay. Of course it isn't. Never trust only one benchmark. I've asked the Great Bridge folks to run their TPC-C benchmark with both zero and small nonzero commit_delay. It will be a couple of days before we have the results, however. Can anyone else offer any comparisons based on other multiuser benchmarks? regards, tom lane
[HACKERS] Re: [BUGS] Turkish locale bug
Sezai YILMAZ [EMAIL PROTECTED] writes: With Turkish locale it is not possible to write SQL queries in CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first are downgraded to "ýnsert" and "unýon". Then "ýnsert" and "unýon" does not match as SQL identifier. Ugh. for(i = 0; yytext[i]; i++) if (isascii((unsigned char)yytext[i]) isupper(yytext[i])) yytext[i] = tolower(yytext[i]); I think it should be better to use another thing which does what function tolower() does but only in English language. This should stay in English locale. I think this will solve the problem. yytext[i] += 32; Hm. Several problems here: (1) This solution would break in other locales where isupper() may return TRUE for characters other than 'A'..'Z'. (2) We could fix that by gutting the isascii/isupper test as well, reducing it to "yytext[i] = 'A' yytext[i] = 'Z'", but I'd prefer to still be able to say that "identifiers fold to lower case" works for whatever the local locale thinks is upper and lower case. It would be strange if identifier folding did not agree with the SQL lower() function. (3) I do not like the idea of hard-wiring knowledge of ASCII encoding here, even if it's unlikely that anyone would ever try to run Postgres on a non-ASCII-based system. I see your problem, but I'm not sure of a solution that doesn't have bad side-effects elsewhere. Ideas anyone? regards, tom lane
