[HACKERS] Encoding names
Hi, I a little work with encodings (Japanese, Latin(s)) and I see that PG use non-standard encoding names. Why is here SJIS instead Shift-JIS, EUC_JP intead EUC-JP, Latin2 instead ISO-8859-2 ? It is not good for example for applications that output data to HTML and needs set correct meta-tags, for this is needful maintain in application PostgreSQL's specific names and standard names and translate between these ... Comments? Karel
[HACKERS] Re: floating point representation
I think a formating mode where only the relevant digits are written to the output would be great as an alternative to the discussed fixed formatting strings. In this context i think of 'relevant' as in the following: 'Output as few characters as possible but ensure that scanf is still able to rebuild the binary reprressentation of the floating point number exactly.' To make this happen we would need to compute a seperate formatting string for each floating point value: E.g. if the binary value is exactly '1.0E00' then we just write '1' to the output, because the rest is just 'ASCII noise' and not neccessary for rebuilding the identical binary value for the given floating point value. The advantage would be, that we only generate as much ASCII data as absolutly neccessary to rebuild the original data exactly. At least this is what I would expect from pg_dump. robert schrem
Re: [HACKERS] Encoding names
> I a little work with encodings (Japanese, Latin(s)) and I see that > PG use non-standard encoding names. > > Why is here SJIS instead Shift-JIS, EUC_JP intead EUC-JP, > Latin2 instead ISO-8859-2 ? > > It is not good for example for applications that output data to HTML and > needs set correct meta-tags, for this is needful maintain in application > PostgreSQL's specific names and standard names and translate between these > ... > > Comments? But HTML meta tags used to use their own encoding names such as x-euc-jp, x-sjis Well, the reaons are: 1) shell does not like "-" (configure and some Unix commands in PostgreSQL accepts encoding names) 2) I don't like longer names BTW, I and Thomas (and maybe others) are interested in implementing CREATE CHRACATER SET staffs in SQL92/99. The encoding names might be changed at that time... -- Tatsuo Ishii
Re: [HACKERS] Encoding names
> But HTML meta tags used to use their own encoding names such as > x-euc-jp, x-sjis Not sure, my mozilla understand "ISO--x", "Shift-JIS" format too. But it's irrelevant, important is that something like "Latin2" or "SJIS" or "EUC_JP" are less standard names. And here aren't HTML only, but other formats too (I-MODE, Wap, XML ...etc). > Well, the reaons are: > > 1) shell does not like "-" (configure and some Unix commands in >PostgreSQL accepts encoding names) > > 2) I don't like longer names Sorry, but both are great traverses and please never say "I don't like" if you talking about already existing standards, it's way to chaos. Sorry of this hard words, but I hope you understand me :-) > BTW, I and Thomas (and maybe others) are interested in implementing > CREATE CHRACATER SET staffs in SQL92/99. The encoding names might be Well, I look forward. Karel
Re: [HACKERS] Re: floating point representation
At 10:19 21/02/01 +0100, Robert Schrem wrote: >The advantage would be, that we only generate as much ASCII data >as absolutly neccessary to rebuild the original data exactly. >At least this is what I would expect from pg_dump. pg_dump is only one side of thre problem, but the simplest solution might be to add an option to dump the hex mantissa, exponent & sign. This should be low-cost and an exact representation of the machine version of the number. The other issues, like what is sent to psql & via interfaces like odbc (currently text) should be application/DBA based and setable on a per-attribute basis. eg. some applications want 1. because the data came from a piece of hardware with a know error, and 1. means 1.+/- 0.5 etc. Maybe this is just an argument for a new 'number with error' type... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Encoding names
> > But HTML meta tags used to use their own encoding names such as > > x-euc-jp, x-sjis > > Not sure, my mozilla understand "ISO--x", "Shift-JIS" format too. > But it's irrelevant, important is that something like "Latin2" or "SJIS" > or "EUC_JP" are less standard names. And here aren't HTML only, but other > formats too (I-MODE, Wap, XML ...etc). They were introduced recently. If I remever correctly, when I started to implemnet the multi-byte fucntionality, most of browsers did not accept "Shift-JIS" as their meta tags. > > Well, the reaons are: > > > > 1) shell does not like "-" (configure and some Unix commands in > >PostgreSQL accepts encoding names) > > > > 2) I don't like longer names > > Sorry, but both are great traverses and please never say "I don't like" > if you talking about already existing standards, it's way to chaos. > > Sorry of this hard words, but I hope you understand me :-) Please understand there is no standard for charset/encoding names in SQL92/99 itself. The SQL standard just says "you can import any charset/encoding from anywhere if you can". Please correct me if I am wrong. However, I do not object to change encoding names if there are enough agrees (and as long as the backward compatibilities are kept). > > BTW, I and Thomas (and maybe others) are interested in implementing > > CREATE CHRACATER SET staffs in SQL92/99. The encoding names might be > > Well, I look forward. Good. -- Tatsuo Ishii
Re: [HACKERS] Encoding names
On Wed, 21 Feb 2001, Tatsuo Ishii wrote:
> Please understand there is no standard for charset/encoding names in
> SQL92/99 itself. The SQL standard just says "you can import any
> charset/encoding from anywhere if you can". Please correct me if I am
> wrong.
In SQL standards not, but all probably known for example ISO names or
some form for this.
> However, I do not object to change encoding names if there are enough
> agrees (and as long as the backward compatibilities are kept).
You not must change current names, you can add to pg_conv_tbl[] new lines
with names synonym for already existing encoding.
An example:
{LATIN1, "LATIN1", 0, latin12mic, mic2latin1, 0, 0},
{LATIN1, "ISO-8859-1", 0, latin12mic, mic2latin1, 0, 0},
And if you order this table by alphabet and in pg_char_to_encoding()
you use Knuth's binary search intead current seq. scannig by for() every
thing will faster and more nice. It's easy.
What? :-)
Karel
Re: [HACKERS] Re: floating point representation
On Wed, 21 Feb 2001, you wrote:
> At 10:19 21/02/01 +0100, Robert Schrem wrote:
> >The advantage would be, that we only generate as much ASCII data
> >as absolutly neccessary to rebuild the original data exactly.
> >At least this is what I would expect from pg_dump.
>
> pg_dump is only one side of thre problem, but the simplest solution might
> be to add an option to dump the hex mantissa, exponent & sign. This should
> be low-cost and an exact representation of the machine version of the number.
The hex dumps should be done in a machine independant way - I think
that's what you ment when stating mantissa, exponent & sign seperatly,
right? I think this whould be a good solution...
> The other issues, like what is sent to psql & via interfaces like odbc
> (currently text) should be application/DBA based and setable on a
> per-attribute basis.
You think of an additional tag in a CREATE TABLE instruction like
CREATE TABLE temperature (
id id,
messure_time timestamp default now() formatted as "hhmmmdd",
value float formatted as "%3.2f"
);
or maybe
CREATE TABLE temperature (
id id,
messure_time("hhmmmdd") timestamp default now(),
value("%3.2f") float
);
or is there something in SQL99 ?
> eg. some applications want 1. because the data
> came from a piece of hardware with a know error, and 1. means 1.+/-
> 0.5 etc. Maybe this is just an argument for a new 'number with error'
> type...
I think a float value in a database column has no known error
range and therefore we should not care about the 'physical' error
of a value in this context. Just think of a computed column in a
VIEW - how can we know for shure how percise such a result is if
we don't have any additional information about the messurement
errors of all operands (or constants) involved.
If you would introduce a new type - 'number with error' - this
would be totally different and a big contribution to the solution
of this. Then you can also handle errors like 1.+/-0.2
percisely - witch you can't by only formatting 1..
robert schrem
[HACKERS] Re: Encoding names
> You not must change current names, you can add to pg_conv_tbl[] new lines
> with names synonym for already existing encoding...
> {LATIN1, "LATIN1", 0, latin12mic, mic2latin1, 0, 0},
> {LATIN1, "ISO-8859-1", 0, latin12mic, mic2latin1, 0, 0},
> And if you order this table by alphabet and in pg_char_to_encoding()
> you use Knuth's binary search intead current seq. scannig by for() every
> thing will faster and more nice. It's easy.
As you probably know, there is already a binary search algorithm coded
up for the date/time string lookups in utils/adt/datetime.c. Since that
lookup caches the last value (which could be done here too) most lookups
are immediate.
Are you proposing to make a change Karel, or just encouraging others? :)
- Thomas
Re: [HACKERS] beta5 ...
Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?
On Wed, 21 Feb 2001, Hannu Krosing wrote:
> Justin Clift wrote:
> >
> > I was just thinking that perhaps as part of the "beta" release process
> > it would be worthwhile saying "New beta about to be released" (or
> > similar) and then have the appropriate people for each platform/OS do a
> > compile against the up-to-the-minute CVS and give a yes/no for each of
> > their platforms.
>
> What would the big advantage to releasing the beta and testing _that_ be
> ?
>
> Apart from delaying the beta, that is ;) ?
>
> It would be nice if someone (pgsql inc., great bridge, etc.) provided a
> central web page for registering the results so that you won't need to
> scan athe whole list to find out if your platform is already tested.
>
> --
> Hannu
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
[HACKERS] Re: Encoding names
On Wed, 21 Feb 2001, Thomas Lockhart wrote:
> > You not must change current names, you can add to pg_conv_tbl[] new lines
> > with names synonym for already existing encoding...
> > {LATIN1, "LATIN1", 0, latin12mic, mic2latin1, 0, 0},
> > {LATIN1, "ISO-8859-1", 0, latin12mic, mic2latin1, 0, 0},
> > And if you order this table by alphabet and in pg_char_to_encoding()
> > you use Knuth's binary search intead current seq. scannig by for() every
> > thing will faster and more nice. It's easy.
>
> As you probably know, there is already a binary search algorithm coded
> up for the date/time string lookups in utils/adt/datetime.c. Since that
> lookup caches the last value (which could be done here too) most lookups
> are immediate.
>
> Are you proposing to make a change Karel, or just encouraging others? :)
>
No problem for me. Do you want patch with this to tommorow breakfast?
IMHO it's acceptable for current 7.1 too, it's really small change.
Or do it Tatsuo?
Karel
Re: [HACKERS] SunOS4
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > included are patched for *7.0.x*. Sould I make same changes to 7.1? > Comments anyone? I think some of these issues are already handled in current sources, but sure, we want to be able to run on SunOS. Portability is a good thing. I'd suggest consulting with Peter Eisentraut about the shared library issues; he's overhauled the Makefiles enough that there may be a different or better way to do that part now. regards, tom lane
Re: [HACKERS] beta5 ...
On Wed, 21 Feb 2001, Tom Lane wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > Vince, is this something that PostgreSQL.Org can have on the web page > > relatively quickly? > > > On Wed, 21 Feb 2001, Hannu Krosing wrote: > >> It would be nice if someone (pgsql inc., great bridge, etc.) provided a > >> central web page for registering the results so that you won't need to > >> scan athe whole list to find out if your platform is already tested. > > Sounded like a great idea to me too. If Vince doesn't want to mess with > it, I'll try to stir up some interest at Great Bridge. Something like this, I think, is more appropriate on the project site, that's all ...
Re: [HACKERS] floating point representation
Philip Warner writes: > At 22:29 20/02/01 +0100, Peter Eisentraut wrote: > >Tom Lane writes: > >> And we frequently see questions from users about how they can display > >> fewer digits than the system wants to give them --- or, more > >> generally, format the output in some special form. > > > >to_char() should serve those people. > > > > This is not a good solution if what you want (as a user) is consistency of > output no matter who retrieves the data; people should not have to wrap > every SELECT field in to_char to get the precision/format they want. Views should serve those people. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] beta5 ...
Peter Eisentraut wrote: > Hannu Krosing writes: > > It would be nice if someone (pgsql inc., great bridge, etc.) provided a > > central web page for registering the results so that you won't need to > > scan athe whole list to find out if your platform is already tested. > "Platform already tested" is a misguided concept. Almost any machine is > customized or deviating in some form or other. A listing of the form > beta1 beta2 ... > Linux ok ok > Solaris ok broken > ... > is, IMHO, worse than useless, because it would actually decrease the > amount of wide-spread, diverse testing. It goes even further than that, of course -- there are different versions to worry about. As a hypothetical, suppose for a moment that PostgreSQL works fine on a Linux 2.2.17 box with glibc 2.1.3, but does not work fine on Linux 2.4.1 with glibc 2.2 due to some undocumented change to strncmp() (;-)). Currently, we're not that fine-grained -- while regression results are useful for ascertaining what is and isn't supported, the regression results are very dependent on the environment of the machine. Any process that would discourage widespread testing is not good, IMHO. Having a form by which you could register pass/fail/diffs for your particular platform/environment could be good, with a blank slate each release. But a blanket 'we support Linux' is, IMHO, not good -- _which_ Linux? 1.0? 1.2? 2.0? 2.0.38 but not 2.0.15? With libc 4 in a.out? Or do you have to have ELF Libc 5? Libc 5.2.38 works, but 5.4.44 doesn't? Glibc 2.0.5 but not 2.1.3? RedHat kernel 2.2.17 but not SuSE kernel 2.2.17? And, the worst: RedHat kernel 2.2.18 for RedHat 7 versus RedHat kernel 2.2.18 for RedHat 6.2 (the kernel patches applied could in fact be different enough to matter)? These are all hypothetical examples, of course -- but Linux is not the only platform that has these versioning problems just waiting to bite. Linux probably has more of them than most, but it is not alone in having them. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] low priority postmaster threads?
Is there any way in psql to connect to a database and reduce the run priority of the child thread it kicks off ? i.e. equivalent of 'nice' on the thread? >From first looks at the code, it seems to fork off the process and there is a pid that can be niced. If an extra run level parameter is passed in to the PQExec interface (defaulted for compatibility with older code), would it work? This assumes that there isn't already a mechanism to reduce the priority of specific queries. What I am looking for is a postgres system that runs 100 users or so at 'full speed', and major day long queries at a 'when idle' priority. Cheers, Chris
[HACKERS] Re: Encoding names
> > As you probably know, there is already a binary search algorithm coded > > up for the date/time string lookups in utils/adt/datetime.c. Since that > > lookup caches the last value (which could be done here too) most lookups > > are immediate. > > > > Are you proposing to make a change Karel, or just encouraging others? :) > > > > No problem for me. Do you want patch with this to tommorow breakfast? > IMHO it's acceptable for current 7.1 too, it's really small change. > > Or do it Tatsuo? Please go ahead. By the way, there is one more place you need to tweak the encoding name table. Take a look at interfaces/libpq/fe-connect.c. It's ugly to have simlilar tables in two places, but I did not find better way to avoid to link huge Unicode conversion tables in the frontend. -- Tatsuo Ishii
Re: [HACKERS] beta5 ...
Hannu Krosing writes: > It would be nice if someone (pgsql inc., great bridge, etc.) provided a > central web page for registering the results so that you won't need to > scan athe whole list to find out if your platform is already tested. "Platform already tested" is a misguided concept. Almost any machine is customized or deviating in some form or other. A listing of the form beta1 beta2 ... Linux ok ok Solaris ok broken ... is, IMHO, worse than useless, because it would actually decrease the amount of wide-spread, diverse testing. I wouldn't mind an automated process that builds and runs the test suite regularly on many machines to inform developers during the development cycle that they broke something really bad, but to make this part of the beta testing process is sheer folly. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: Encoding names
On Thu, 22 Feb 2001, Tatsuo Ishii wrote: > > > As you probably know, there is already a binary search algorithm coded > > > up for the date/time string lookups in utils/adt/datetime.c. Since that > > > lookup caches the last value (which could be done here too) most lookups > > > are immediate. > > > > > > Are you proposing to make a change Karel, or just encouraging others? :) > > > > > > > No problem for me. Do you want patch with this to tommorow breakfast? > > IMHO it's acceptable for current 7.1 too, it's really small change. > > > > Or do it Tatsuo? > > Please go ahead. By the way, there is one more place you need to tweak > the encoding name table. Take a look at > interfaces/libpq/fe-connect.c. It's ugly to have simlilar tables in > two places, but I did not find better way to avoid to link huge > Unicode conversion tables in the frontend. Hmm, I see. It's realy a little ugly maintain two places with same things. What this solution: * split (on backend) pg_conv_tbl[] into two tables: encstr2enc[]- for encoding names (strings) to encode 'id'. This table will sort by alphabet. pg_conv_tbl[] - table with encoding 'id' and with encoding routines. This table will order by encoding 'id' and this order allows found relevant routines, an example: pg_conv_tbl[ LATIN1 ] This solution allows to use and share on libpq and backend one encstr2enc[] table and basic functions those works with this table -- like pg_char_to_encoding(). May be will better define for encoding 'id' separate enum datetype instead current mistake-able '#define'. Karel
RE: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
> Tom Lane wrote: > > > > > platform) i686-pc-linux-gnu, compiled by GCC > egcs-2.91.60(turbolinux 4.2) > > > min delay) 10msec according to your test program. > > > -B) 64 (all other settings are default) > > > > Thanks. Could I trouble you to run it again with a larger -B, say > > 1024 or 2048? What I've found is that at -B 64, the benchmark is > > so constrained by limited buffer space that it doesn't reflect > > performance at a more realistic production setting. > > > > Hmm the result doesn't seem that obvious. > I tried with -B 1024 10 times for commit_delay=0 and 1 respectively. The average result of 'pgbench -c 10 -t 100' is as follows. [commit_delay=0] 26.462817(including connections establishing) 26.788047(excluding connections establishing) [commit_delay=1] 27.630405(including connections establishing) 28.042666(excluding connections establishing) Hiroshi Inoue
Re: [HACKERS] beta5 ...
On Wed, 21 Feb 2001, The Hermit Hacker wrote:
>
> Vince, is this something that PostgreSQL.Org can have on the web page
> relatively quickly?
The beta or registering the results? After the last time I won't
put beta releases on the website, but if you want the results thing
it can be done in a short time. Just tell me what info you want
in it and it'll be there.
Vince.
>
> On Wed, 21 Feb 2001, Hannu Krosing wrote:
>
> > Justin Clift wrote:
> > >
> > > I was just thinking that perhaps as part of the "beta" release process
> > > it would be worthwhile saying "New beta about to be released" (or
> > > similar) and then have the appropriate people for each platform/OS do a
> > > compile against the up-to-the-minute CVS and give a yes/no for each of
> > > their platforms.
> >
> > What would the big advantage to releasing the beta and testing _that_ be
> > ?
> >
> > Apart from delaying the beta, that is ;) ?
> >
> > It would be nice if someone (pgsql inc., great bridge, etc.) provided a
> > central web page for registering the results so that you won't need to
> > scan athe whole list to find out if your platform is already tested.
> >
> > --
> > Hannu
> >
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
>
>
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directoryhttp://www.camping-usa.com
Online Giftshop Superstorehttp://www.cloudninegifts.com
==
Re: [HACKERS] SunOS4
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tatsuo Ishii writes: >> o regex/utils.h included twice somewhere. I added #ifndef >> UTILS_H... to utils.h > Okay. Actually, the problem is probably gone. c.h was including regex/utils.h if the platform didn't have memmove(), but I thought that was a very ugly thing to do and moved the memmove() macro to c.h instead. However, an #ifndef UTILS_H is harmless and good practice, so I don't object to putting it in anyway. (You might want to make the symbol REGEX_UTILS_H, though, to avoid possible conflicts with other files named utils.h ...) regards, tom lane
Re: [HACKERS] beta5 ...
On Wed, 21 Feb 2001, The Hermit Hacker wrote: > On Wed, 21 Feb 2001, Vince Vielhaber wrote: > > > On Wed, 21 Feb 2001, The Hermit Hacker wrote: > > > > > > > > Vince, is this something that PostgreSQL.Org can have on the web page > > > relatively quickly? > > > > The beta or registering the results? After the last time I won't > > put beta releases on the website, but if you want the results thing > > it can be done in a short time. Just tell me what info you want > > in it and it'll be there. > > Hrmmm ... some sort of input form where someone can enter OS specific > info, and maybe upload the results of the regression tests as far as > 'failed' or 'succeeded'? the report generated would list the OS info and > x out of y tests failed ... and a link to a full listing of which > failed/succeeded? Lemme see what I can cobble together taking into consideration some of the things Lamar and Peter also mentioned. Note: I'm probably 450 messagees behind due to a 2 day dsl outage; I may have missed some of the conversation. Some messages trickled in, the rest flooded in over night. I may be nearing the time for incoming mail folders :) Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
[HACKERS] Bug: COUNT() and ExecEvalAggref error
I've looked through my archives of pgsql-general and pgsql-hackers and
haven't seen this, but I do tend to flush the deleted messages
occasionally. I'm trying to get a build off the current CVS tree, but
my working build is from Sunday evening, so I feel moderately current.
Two builds of 7.1beta4 from the CVS tree. The one on my production
machine was built January 29, the one on my development machine was
built from sources gotten Sunday evening.
When I do this:
$ /usr/local/pgsql/bin/createdb test
$ /usr/local/pgsql/bin/psql test
test=# create table abc (id serial, stuff text);
test=# insert into abc (stuff) values ('xyz');
test=# insert into abc (stuff) values ('xyz');
test=# insert into abc (stuff) values ('xyz');
test=# insert into abc (stuff) values ('qrs');
test=# insert into abc (stuff) values ('qrs');
test=# insert into abc (stuff) values ('qrs');
test=# insert into abc (stuff) values ('qrs');
test=# insert into abc (stuff) values ('qrs');
test=# select count(id) from abc;
On my production machine (PosgreSQL built from CVS on January 29) I
get the expected result:
count
---
8
(1 row)
On my development machine (Built from CVS late Sunday, February 18), I
get:
test=# select count(id) from abc;
ERROR: ExecEvalAggref: no aggregates in this expression context
test=#
Apologies if this has gone by already, I'm in the process of trying to
get an absolutely current CVS update to build and if anyone's got
suggestions on where to start before I dive into the PostgreSQL code
whole hog for the first time I'd sure appreciate it.
Don't think it matters, but just in case, development box is:
Linux wynand 2.2.17 #7 Wed Nov 8 09:47:05 PST 2000 i586 unknown
Production server, and the machine that the production server binaries
were built on, both of which work:
Linux mail 2.2.12 #6 Tue Jan 18 17:49:47 PST 2000 i586 unknown
Linux francon 2.2.18 #2 SMP Sun Jan 28 20:10:18 PST 2001 i686 unknown
All using libc-2.1.3.so
Dan
Re: [HACKERS] Bug: COUNT() and ExecEvalAggref error
Dan Lyke <[EMAIL PROTECTED]> writes: > On my development machine (Built from CVS late Sunday, February 18), I > get: >test=# select count(id) from abc; >ERROR: ExecEvalAggref: no aggregates in this expression context Try make distclean, configure, make all. Someone else reported this same symptom recently due to having inconsistent object files. In general, anytime you do "cvs update", the safest approach is a make distclean and full rebuild. If you have not enabled dependency tracking then that's the *only* procedure that will work reliably. If you do use --enable-depend then you may be able to get away with partial rebuilds, but I don't trust that feature myself. I figure I can do an awful lot of automatic rebuilds in the time it will cost me to track down even one "bug" caused by inconsistent files. regards, tom lane
Re: [HACKERS] beta5 ...
Vince Vielhaber wrote: > the things Lamar and Peter also mentioned. Note: I'm probably 450 > messagees behind due to a 2 day dsl outage; I may have missed some of > the conversation. Some messages trickled in, the rest flooded in over > night. I may be nearing the time for incoming mail folders :) Join the club. I have just finished configuring my Netscape e-mail for incoming folders -- _important_ direct e-mails (having to to with my actual job) were getting lost in and amongst the various lists I am a member of. I get around 600 e-mails per day on fifteen or so different mailing lists (the ones at PostgreSQL.org, a half dozen at Broadcast.net, Bugtraq/Linux-alert/RedHat-announce, redhat-beta, AOLserver/OpenNSD/OpenACS, and a handful of Linux announce lists, unixODBC, CERT, plus all of our Internet listeners). Netscapes filters are a lifesaver! Of course, there are other more capable packages out there, but Netscape works the same on Win9x and Linux, both of which are in use on my notebook. I have to keep up, or the e-mail flood after a couple of days is just about unbearable. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] SunOS4
> > > o SunOS4 does not have atexit (used in psql). --> igore it > > > > Maybe on_exit() is available, or even more portable? > > Let me check it. SunOS4 has on_exit. Can we change atexit to on_exit? > > > o to make shared library I have added an entry for SunOS4 in > > > Makefile.shlib. > > > > I'm not sure that entry is right. Libtool wants it to look like > > > > $(LD) -assert pure-text -Bshareable > > > > you have > > > > $(LD) -dc -dp -Bdynamic > > It comes from our makefiles/Makefile.sunos4. Let me check if what > Libtool suggests works. It doesn't work. Probably that is for GNU ld? On sparc platforms, we usually do not use GNU ld (I don't remember the reason though). However $(LD) -assert pure-text -Bdynamic works. > > > o to make shared libraries (such as libpgeasy.so) relying on libpq, > > > "ld foo.o bar.o ... -L ../libpq -lpq" is executed but fails. I > > > changed it to: > > > ld foo.o bar.o ... ../libpq.a > > > instead. > > > > Can you elaborate on why that's necessary? Perhaps a problem with the > > command line (see above)? $(LD) -assert pure-text -Bdynamic (eliminating -dc -dp) works with -L ../libpq -lpq. But is it safe? Can we live without -dc -dp? SunOS4 guru anywhere? -- Tatsuo Ishii
Re: [HACKERS] beta5 ...
On Wed, 21 Feb 2001, The Hermit Hacker wrote: > On Wed, 21 Feb 2001, Vince Vielhaber wrote: > > > On Wed, 21 Feb 2001, The Hermit Hacker wrote: > > > > > > > > Vince, is this something that PostgreSQL.Org can have on the web page > > > relatively quickly? > > > > The beta or registering the results? After the last time I won't > > put beta releases on the website, but if you want the results thing > > it can be done in a short time. Just tell me what info you want > > in it and it'll be there. > > Hrmmm ... some sort of input form where someone can enter OS specific > info, and maybe upload the results of the regression tests as far as > 'failed' or 'succeeded'? the report generated would list the OS info and > x out of y tests failed ... and a link to a full listing of which > failed/succeeded? http://hub.org/~vev/regress.php What other info is needed to distinguish these systems? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] SunOS4
> > o no RAND_MAX or EXIT_FAILURE found. I simply added them to c.h.
>
> EXIT_FAILURE is defined in src/bin/psql/settings.h; I can't find it used
> outside psql.
So SunOS should be ok with this in current.
> RAND_MAX should be inside an #ifndef RAND_MAX, not in a
> SunOS specific section.
Ok.
> > o regex/utils.h included twice somewhere. I added #ifndef
> > UTILS_H... to utils.h
>
> Okay.
I will add REGEX_UTILS_H per Tom's suggestion.
> > o SunOS4 does not have strdup, strtoul. --> use backend/port/strtoul.c
> > etc.
>
> Okay. Instead of ../../etc. in makefiles you should use $(top_srcdir) or
> $(top_builddir).
I see.
> > o SunOS4 does not have atexit (used in psql). --> igore it
>
> Maybe on_exit() is available, or even more portable?
Let me check it.
> > o SunOS4 does not have getopt. --> use utils/getopt.c. also getopt.h
> > need to be created, and checking for getopt is needed to configure.in.
>
> Ugh.
>
> #include "../../utils/getopt.h" is definitely not good.
>
> + #ifndef HAVE_GETOPT_H
> + char *__progname = "pg_id";
> + #endif
>
> seems to be misguided.
But our getopt implementaion requires
char *__progname = "pg_id";
no?
> The getopt.h file doesn't seem necessary. The external variables should
> be defined in every program that needs them. The getopt() function
> doesn't need to be declared.
I agree with we don't need getopt.h.
> > o to make shared library I have added an entry for SunOS4 in
> > Makefile.shlib.
>
> I'm not sure that entry is right. Libtool wants it to look like
>
> $(LD) -assert pure-text -Bshareable
>
> you have
>
> $(LD) -dc -dp -Bdynamic
It comes from our makefiles/Makefile.sunos4. Let me check if what
Libtool suggests works.
> > o to make shared libraries (such as libpgeasy.so) relying on libpq,
> > "ld foo.o bar.o ... -L ../libpq -lpq" is executed but fails. I
> > changed it to:
> > ld foo.o bar.o ... ../libpq.a
> > instead.
>
> Can you elaborate on why that's necessary? Perhaps a problem with the
> command line (see above)? Why only ecpg?
Not only ecpg. libpgeasy, libpq++ also.
> > o pg_id needs Makefile.in.
>
> Nothing needs a Makefile.in. Substitution symbols go in Makefile.global.
Oh, things have been changed dramatically since 7.0. I see now.
> > included are patched for *7.0.x*. Sould I make same changes to 7.1?
> > Comments anyone?
>
> 7.0 build patches are pretty much useless for 7.1, I'm afraid. You should
> work with 7.1 before proceeding.
Of course.
BTW, I observe some regression failures under SunOS4 due to the
difference of strtol. It does not detect overflow. So, following
INSERT in regress/sql/int4.sql does not throw an error, but inserts
a random value.
-- bad input values -- should give warnings
INSERT INTO INT4_TBL(f1) VALUES ('1');
What should we do?
--
Tatsuo Ishii
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I doubt that it ever really worked, or could work, to install a new > version over an old one without deleting the old one first. This here is > just one problem. We can't be making these funny workarounds every time > the set of installed user visible files changes. For example, if an older > version had a header file that the new version doesn't have, then user > code that includes this file will still be silently broken. Well, the idea is to make the breakage be not so silent ... regards, tom lane
[HACKERS] Re: beta5 ...
I have a bunch of machines here, some are rather old (K6-200s,P133s, some 486s etc) but they're just collecting dust now. I would be more than happy to install any OS and do build testing for PostgreSQL is there is a need.. What OSes need to have PostgreSQL built/tested on that the developers don't have access to? If I can get the OS (and install it), I would be happy to dedicate those machines to PG build testing.. I could set them up on the network here (proxy, cable modem) or at the office (T1) and give developers access if needed too. I have several FreeBSD boxes running PG beta 4 now, but I'd bet at least one of you is using FreeBSD (and it compiles and installs rather nicely anyway).. -Mitch
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Tom Lane writes: > > Deleting files in the install directory during installation is very > > inappropriate. At least let's try to get rid of it for 7.2. > > I don't like it much either, but I agree with Larry that it's an > essential transition step for now. Perhaps we can remove it again > in 7.2 or 7.3 or so. I doubt that it ever really worked, or could work, to install a new version over an old one without deleting the old one first. This here is just one problem. We can't be making these funny workarounds every time the set of installed user visible files changes. For example, if an older version had a header file that the new version doesn't have, then user code that includes this file will still be silently broken. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Peter Eisentraut <[EMAIL PROTECTED]> [010221 16:09]: > Tom Lane writes: > > > > Deleting files in the install directory during installation is very > > > inappropriate. At least let's try to get rid of it for 7.2. > > > > I don't like it much either, but I agree with Larry that it's an > > essential transition step for now. Perhaps we can remove it again > > in 7.2 or 7.3 or so. > > I doubt that it ever really worked, or could work, to install a new > version over an old one without deleting the old one first. This here is > just one problem. We can't be making these funny workarounds every time > the set of installed user visible files changes. For example, if an older > version had a header file that the new version doesn't have, then user > code that includes this file will still be silently broken. THIS CHANGED WITHIN A BETA CYCLE. THAT SHOULD HAVE WORKED. LER > > -- > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ -- 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] beta5 ...
* Lamar Owen <[EMAIL PROTECTED]> [010221 16:36]: > Vince Vielhaber wrote: > > the things Lamar and Peter also mentioned. Note: I'm probably 450 > > messagees behind due to a 2 day dsl outage; I may have missed some of > > the conversation. Some messages trickled in, the rest flooded in over > > night. I may be nearing the time for incoming mail folders :) > > Join the club. I have just finished configuring my Netscape e-mail for > incoming folders -- _important_ direct e-mails (having to to with my > actual job) were getting lost in and amongst the various lists I am a > member of. I get around 600 e-mails per day on fifteen or so different > mailing lists (the ones at PostgreSQL.org, a half dozen at > Broadcast.net, Bugtraq/Linux-alert/RedHat-announce, redhat-beta, > AOLserver/OpenNSD/OpenACS, and a handful of Linux announce lists, > unixODBC, CERT, plus all of our Internet listeners). Netscapes filters > are a lifesaver! Of course, there are other more capable packages out > there, but Netscape works the same on Win9x and Linux, both of which are > in use on my notebook. > > I have to keep up, or the e-mail flood after a couple of days is just > about unbearable. slocal/procmail/mutt on a Unix Box makes it easier. My Mailing list stuff gets filtered off. LER > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 -- 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
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Larry Rosenman 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...? > Deleting files in the install directory during installation is very > inappropriate. At least let's try to get rid of it for 7.2. I don't like it much either, but I agree with Larry that it's an essential transition step for now. Perhaps we can remove it again in 7.2 or 7.3 or so. regards, tom lane
Re: [HACKERS] SunOS4
Tatsuo Ishii writes: > o c.h 's sunos4 part should not include varargs.h. (Tom has already > fixed it) Instead, stdlib.h and stdarg.h should be included. This should be okay by now. > o no RAND_MAX or EXIT_FAILURE found. I simply added them to c.h. EXIT_FAILURE is defined in src/bin/psql/settings.h; I can't find it used outside psql. RAND_MAX should be inside an #ifndef RAND_MAX, not in a SunOS specific section. > o regex/utils.h included twice somewhere. I added #ifndef > UTILS_H... to utils.h Okay. > o utils/adt/formatting.c rely on sprintf() returns length of formatted > strings. This is not true for SunOS4. I have changed sprintf to > snprintf. Okay. > o SunOS4 does not have strdup, strtoul. --> use backend/port/strtoul.c > etc. Okay. Instead of ../../etc. in makefiles you should use $(top_srcdir) or $(top_builddir). > o SunOS4 does not have atexit (used in psql). --> igore it Maybe on_exit() is available, or even more portable? > o SunOS4 does not have getopt. --> use utils/getopt.c. also getopt.h > need to be created, and checking for getopt is needed to configure.in. Ugh. #include "../../utils/getopt.h" is definitely not good. + #ifndef HAVE_GETOPT_H + char *__progname = "pg_id"; + #endif seems to be misguided. The getopt.h file doesn't seem necessary. The external variables should be defined in every program that needs them. The getopt() function doesn't need to be declared. > o to make shared library I have added an entry for SunOS4 in > Makefile.shlib. I'm not sure that entry is right. Libtool wants it to look like $(LD) -assert pure-text -Bshareable you have $(LD) -dc -dp -Bdynamic > > o to make shared libraries (such as libpgeasy.so) relying on libpq, > "ld foo.o bar.o ... -L ../libpq -lpq" is executed but fails. I > changed it to: > ld foo.o bar.o ... ../libpq.a > instead. Can you elaborate on why that's necessary? Perhaps a problem with the command line (see above)? Why only ecpg? > o pg_id needs Makefile.in. Nothing needs a Makefile.in. Substitution symbols go in Makefile.global. > included are patched for *7.0.x*. Sould I make same changes to 7.1? > Comments anyone? 7.0 build patches are pretty much useless for 7.1, I'm afraid. You should work with 7.1 before proceeding. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: floating point representation
Philip Warner <[EMAIL PROTECTED]> writes: > The other issues, like what is sent to psql & via interfaces like odbc > (currently text) should be application/DBA based and setable on a > per-attribute basis. eg. some applications want 1. because the data > came from a piece of hardware with a know error, and 1. means 1.+/- > 0.5 etc. Maybe this is just an argument for a new 'number with error' > type... FWIW, there is a number-with-error type in contrib/seg ... regards, tom lane
Re: [HACKERS] SunOS4
> Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > o SunOS4 does not have atexit (used in psql). --> igore it > > > > Maybe on_exit() is available, or even more portable? > > > SunOS4 has on_exit. Can we change atexit to on_exit? > > atexit is ANSI C. on_exit is not found here (HPUX) at all. Looks > like we need another configure test :-( ... but I recommend we stick > with atexit as the preferred form. > > regards, tom lane Ok. First test if atexit exists. on_exit is second. -- Tatsuo Ishii
Re: [HACKERS] beta5 ...
The Hermit Hacker <[EMAIL PROTECTED]> writes: > Vince, is this something that PostgreSQL.Org can have on the web page > relatively quickly? > On Wed, 21 Feb 2001, Hannu Krosing wrote: >> It would be nice if someone (pgsql inc., great bridge, etc.) provided a >> central web page for registering the results so that you won't need to >> scan athe whole list to find out if your platform is already tested. Sounded like a great idea to me too. If Vince doesn't want to mess with it, I'll try to stir up some interest at Great Bridge. regards, tom lane
Re: [HACKERS] SunOS4
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > o SunOS4 does not have atexit (used in psql). --> igore it > > Maybe on_exit() is available, or even more portable? > SunOS4 has on_exit. Can we change atexit to on_exit? atexit is ANSI C. on_exit is not found here (HPUX) at all. Looks like we need another configure test :-( ... but I recommend we stick with atexit as the preferred form. regards, tom lane
Re: [HACKERS] beta5 ...
Hi Vince, That's really nifty. I don't know how to word it, but I think it might be worth including something to find out if the machine was "out-of-the box" with just the recommended installation utils (i.e. a "new build" of AIX, NT, Solaris, etc, then gcc, bison or whatever) vs. a machine that has been actively used/developed with for a while. This is so we can accurately know if a particular version/beta of PostgreSQL compiles on a stock(-ish) system or if the successful/failed reports are only coming from those machines with updated/newer/different things added. Regards and best wishes, Justin Clift Database Administrator Vince Vielhaber wrote: > > > http://hub.org/~vev/regress.php > > What other info is needed to distinguish these systems? > > Vince. > -- > == > Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net > 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking > Online Campground Directoryhttp://www.camping-usa.com >Online Giftshop Superstorehttp://www.cloudninegifts.com > ==
Re: [HACKERS] beta5 ...
On Wed, 21 Feb 2001, Vince Vielhaber wrote:
> On Wed, 21 Feb 2001, The Hermit Hacker wrote:
>
> >
> > Vince, is this something that PostgreSQL.Org can have on the web page
> > relatively quickly?
>
> The beta or registering the results? After the last time I won't
> put beta releases on the website, but if you want the results thing
> it can be done in a short time. Just tell me what info you want
> in it and it'll be there.
Hrmmm ... some sort of input form where someone can enter OS specific
info, and maybe upload the results of the regression tests as far as
'failed' or 'succeeded'? the report generated would list the OS info and
x out of y tests failed ... and a link to a full listing of which
failed/succeeded?
> > Vince.
>
> >
> > On Wed, 21 Feb 2001, Hannu Krosing wrote:
> >
> > > Justin Clift wrote:
> > > >
> > > > I was just thinking that perhaps as part of the "beta" release process
> > > > it would be worthwhile saying "New beta about to be released" (or
> > > > similar) and then have the appropriate people for each platform/OS do a
> > > > compile against the up-to-the-minute CVS and give a yes/no for each of
> > > > their platforms.
> > >
> > > What would the big advantage to releasing the beta and testing _that_ be
> > > ?
> > >
> > > Apart from delaying the beta, that is ;) ?
> > >
> > > It would be nice if someone (pgsql inc., great bridge, etc.) provided a
> > > central web page for registering the results so that you won't need to
> > > scan athe whole list to find out if your platform is already tested.
> > >
> > > --
> > > Hannu
> > >
> >
> > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> > Systems Administrator @ hub.org
> > primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
> >
> >
>
> --
> ==
> Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
> 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
> Online Campground Directoryhttp://www.camping-usa.com
>Online Giftshop Superstorehttp://www.cloudninegifts.com
> ==
>
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
Larry Rosenman 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...? Deleting files in the install directory during installation is very inappropriate. At least let's try to get rid of it for 7.2. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
RE: [HACKERS] beta5 ...
What about adding a field where they paste the output of 'uname -a' on their system...? Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Justin Clift > Sent: Thursday, February 22, 2001 12:52 PM > To: Vince Vielhaber > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] beta5 ... > > > Hi Vince, > > That's really nifty. > > I don't know how to word it, but I think it might be worth including > something to find out if the machine was "out-of-the box" with just the > recommended installation utils (i.e. a "new build" of AIX, NT, Solaris, > etc, then gcc, bison or whatever) vs. a machine that has been actively > used/developed with for a while. > > This is so we can accurately know if a particular version/beta of > PostgreSQL compiles on a stock(-ish) system or if the successful/failed > reports are only coming from those machines with updated/newer/different > things added. > > Regards and best wishes, > > Justin Clift > Database Administrator > > Vince Vielhaber wrote: > > > > > > > http://hub.org/~vev/regress.php > > > > What other info is needed to distinguish these systems? > > > > Vince. > > -- > > > == > > Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED] http://www.pop4.net > 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking > Online Campground Directoryhttp://www.camping-usa.com >Online Giftshop Superstorehttp://www.cloudninegifts.com > ==
Re: [HACKERS] low priority postmaster threads?
I wrote: > Chris Storah <[EMAIL PROTECTED]> writes: >> What I am looking for is a postgres system that runs 100 users or so at >> 'full speed', and major day long queries at a 'when idle' priority. > The trouble here is that CPU nice doesn't (on most platforms) change the > behavior of the I/O scheduler, so this would only be of use to the > extent that your queries are CPU bound and not I/O bound. Now that I think twice, there's an even more severe problem with trying to nice() down an individual backend, namely priority inversion. What happens when the low-priority process holds some lock or other, and then a higher-priority process comes along and wants the lock? The high-priority process has to wait, that's what. But there's no mechanism to raise the priority of the lower-priority lock holder, which means that the high-priority process is now effectively lowered to the lower priority; it may have to wait quite a long time, if there are other high-priority processes sucking CPU away from the low-priority guy. In short, forget about nice'ing an individual backend; you probably won't like the results. Sorry. regards, tom lane
Re: [HACKERS] low priority postmaster threads?
Chris Storah <[EMAIL PROTECTED]> writes: > Is there any way in psql to connect to a database and reduce the run > priority of the child thread it kicks off ? > i.e. equivalent of 'nice' on the thread? Not at the moment, though it'd be a fairly trivial hack on postgres.c to add a "-nice n" backend switch, which you could then specify at connection time via PGOPTIONS. > What I am looking for is a postgres system that runs 100 users or so at > 'full speed', and major day long queries at a 'when idle' priority. The trouble here is that CPU nice doesn't (on most platforms) change the behavior of the I/O scheduler, so this would only be of use to the extent that your queries are CPU bound and not I/O bound. regards, tom lane
RE: [HACKERS] PHP 4.0.4pl1 / Beta 5
but the changes in the include structure force us to. If someone includes the old ones that aren't supposed to be there, we cause non-obvious compile errors. LER -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 21, 2001 10:56 AM To: Larry Rosenman Cc: Tom Lane; Sascha Schumann; PostgreSQL Hackers List; Bruce Momjian Subject: Re: [HACKERS] PHP 4.0.4pl1 / Beta 5 Larry Rosenman 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...? Deleting files in the install directory during installation is very inappropriate. At least let's try to get rid of it for 7.2. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] RE: Re: [ADMIN] v7.1b4 bad performance
Oops. I rechecked the start up script, and the 7.0.3 doesn't have fsync off or whatever. Dunno why I thought it was on (heh maybe because it was a lot faster than 6.5.3!). Hmm, this means 7.0.3 is quite fast... Cheerio, Link.
[HACKERS] RE: Re: [ADMIN] v7.1b4 bad performance
Just another data point. I downloaded a snapshot yesterday - Changelogs dated Feb 20 17:02 It's significantly slower than "7.0.3 with fsync off" for one of my webapps. 7.0.3 with fsync off gets me about 55 hits per sec max (however it's interesting that the speed keeps dropping with continued tests). ( PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66) For 7.1b4 snapshot I get about 23 hits per second (drops gradually too). I'm using Pg::DBD compiled using the 7.1 libraries for both tests. (PostgreSQL 7.1beta4 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66) For a simple "select only" webapp I'm getting 112 hits per sec for 7.0.3. and 109 hits a sec for the 7.1 beta4 snapshot. These results remain quite stable over many repeated tests. The first webapp does a rollback, begin, select, update, commit, begin, a bunch of selects in sequence and rollback. So my guess is that the 7.1 updates (with default fsync) are significantly slower than 7.0.3 fsync=off now. But it's interesting that the updates slow things down significantly. Going from 50 to 30 hits per second after a few thousand hits for 7.0.3, and 23 to 17 after about a thousand hits for 7.1beta4. For postgresql 7.0.3 to speed things back up from 30 to 60 hits per sec I had to do: lylyeoh=# delete from session; DELETE 1 lylyeoh=# vacuum; vacuum analyze; VACUUM NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset VACUUM (Not sure why the above happened, but I repeated the vacuum again for good measure) lylyeoh=# vacuum; vacuum analyze; VACUUM VACUUM Then I ran the apachebench again (after visiting the webpage once to create the session). Note that even with only one row in the session table it kept getting slower and slower as it kept getting updated, even when I kept trying to vacuum and vacuum analyze it. I had to delete the row and vacuum only then was there a difference. I didn't try this on 7.1beta4. Cheerio, Link.
