Re: [HACKERS] Reducing the overhead of NUMERIC data
On Thu, 2005-11-03 at 10:32 -0500, Tom Lane wrote: I'd feel a lot happier about this if we could keep the dynamic range up to, say, 10^512 so that it's still true that NUMERIC can be a universal parse-time representation. That would also make it even more unlikely that anyone would complain about loss of functionality. To do that we'd need 8 bits for weight (-128..127 for a base-10K exponent is enough) but we need 9 bits for dscale which does not quite fit. I think we could make it go by cramming the sign and the high-order dscale bit into the first NumericDigit --- the digit itself can only be 0.. so there are a couple of bits to spare. This probably *would* slow down packing and unpacking of numerics, but just by a couple lines of C. Arguably the net reduction in I/O costs would justify that. I've got a working version of the code using the above scheme, with these additional wrinkles: NaN is indicated by weight=-128, giving a dynamic range of 10^508. Zeroes are fully compressed, except when the Scale 255. In that case, the first digit is present to signify the presence of the high order Scale bit. Comments? Once 8.1 is released, I'll go back and see if I can improve the coding in a few days with fresh eyes, then submit a patch. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PERFORM] insert performance for win32
On Fri, 2005-11-04 at 13:21 -0500, Bruce Momjian wrote: David Fetter wrote: On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote: I'm inclined to treat this as an outright bug, not just a minor performance issue, because it implies that a sufficiently long psql script would probably crash a Windows machine. Ouch. In light of this, are we *sure* what we've got a is a candidate for release? Good point. It is something we would fix in a minor release, so it doesn't seem worth doing another RC just for that. Will this be documented in the release notes? If we put unimplemented features in TODO, where do we list things we regard as bugs? Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] pgInstaller 8.1 built
Morning, pgInstaller 8.1 has been built and uploaded to ftp.postgresql.org/pub/win32. Please take a look if you can and report any glaring errors. Hiroshi; I think we're ready for the Japanese version whenever you're ready :-) Regards, Dave. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Reducing the overhead of NUMERIC data
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2005-11-03 at 10:32 -0500, Tom Lane wrote: I think we could make it go by cramming the sign and the high-order dscale bit into the first NumericDigit --- the digit itself can only be 0.. so there are a couple of bits to spare. I've got a working version of the code using the above scheme, Really? After I woke up a bit more I realized there was only one bit and change to spare, not two, so I don't see how it would work. (Unless you want to force a minimum of two NumericDigits when the dscale exceeds 255, and flag the scale in the second one --- which might be OK but it's getting messier and messier...) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PG 8.1 supported platforms list: IRIX is MIA
Gavin Sherry [EMAIL PROTECTED] writes: I had a colleague test for me on his IRIX (6.5?) MIPSPRO machine. The following regression tests fail: http://treehou.se/~finn/regression.diffs Hm, looks like strtod() has some bizarre behavior for input infinity on that machine (NOT just failing to recognize it, but doing something actively incorrect --- we've seen such bugs on Solaris). I had a success report from someone else on Friday, so maybe this problem is confined to specific IRIX versions? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PERFORM] insert performance for win32
Simon Riggs wrote: On Fri, 2005-11-04 at 13:21 -0500, Bruce Momjian wrote: David Fetter wrote: On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote: I'm inclined to treat this as an outright bug, not just a minor performance issue, because it implies that a sufficiently long psql script would probably crash a Windows machine. Ouch. In light of this, are we *sure* what we've got a is a candidate for release? Good point. It is something we would fix in a minor release, so it doesn't seem worth doing another RC just for that. Will this be documented in the release notes? If we put unimplemented features in TODO, where do we list things we regard as bugs? No need, I think. It was patched 2 days ago. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pgInstaller 8.1 built
Morning, pgInstaller 8.1 has been built and uploaded to ftp.postgresql.org/pub/win32. Please take a look if you can and report any glaring errors. Hiroshi; I think we're ready for the Japanese version whenever you're ready :-) Thanks! However, I have still left much work. I needed of several days. then, do my best. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pgInstaller 8.1 built
-Original Message- From: Hiroshi Saito [mailto:[EMAIL PROTECTED] Sent: Sun 11/6/2005 6:11 PM To: Dave Page Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] pgInstaller 8.1 built Hiroshi; I think we're ready for the Japanese version whenever you're ready :-) Thanks! However, I have still left much work. I needed of several days. then, do my best. We can't ask any more than that :-) /D ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] somebody could explain this?
yes, MAJOR goof on my part. My brain cells were not firing quite right :( For those really interested, here are some resources: http://www.cs.wisc.edu/~cs354-1/cs354/karen.notes/reps.flpt.html http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane Sent: Friday, November 04, 2005 11:52 AM To: [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Subject: Re: [OT] somebody could explain this? Otto Hirr [EMAIL PROTECTED] writes: Most notably, the IEEE rep, either single or double, most certainly has the ability to store the EXACT value for 0.1. Oh really? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PG 8.1 supported platforms list: IRIX is MIA
On Fri, 4 Nov 2005, Tom Lane wrote: The 8.1 supported-platforms list is looking pretty good, I think -- we don't have updates for every single combination of OS and hardware, but we have updates for every OS and at least one instance of all supported CPU types. Except IRIX. There's been no port report since Robert Bruccoleri confirmed PG 7.4 worked. If we can't get a confirmation of that I fear we ought to drop it down to the unsupported list. Can anyone test 8.1RC1 on IRIX? I had a colleague test for me on his IRIX (6.5?) MIPSPRO machine. The following regression tests fail: http://treehou.se/~finn/regression.diffs Gavin ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgInstaller 8.1 built
On Mon, 7 Nov 2005, Hiroshi Saito wrote: Morning, pgInstaller 8.1 has been built and uploaded to ftp.postgresql.org/pub/win32. Please take a look if you can and report any glaring errors. Hiroshi; I think we're ready for the Japanese version whenever you're ready :-) Thanks! However, I have still left much work. I needed of several days. then, do my best. several days isn't a biggie ... that's one of the reasons why we left such a gap between bundle and announce, there are more and more 'packges' that have to be built :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] broken comment justification logic in new pgindent
I'm noticing that the latest pgindent run has frequently rejustified block comments to end in column 80 or 81, causing them to wrap in an ugly way (at least in emacs). I thought the agreement was to limit lines to 79 chars max? For one example see lines 475 ff in /src/backend/access/nbtree/nbtpage.c --- the first lines of two successive paragraphs in the comment have been made too long, which they were not before. I'm not sure about this offhand, but I think that all the cases I've seen have involved first lines of paragraphs inside block comments. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] SIGSEGV taken on 8.1 during dump/reload
Hey all, I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a segmentation violation 1 hour into the operation. My plan is to re-do the dump/restore, and if it fails again, to re-compile with debug and cassert, and try to get a core. The command line was (8.1.0 is on port 5433): time pg_dumpall -c -v | psql -p 5433 -d template1 template1=# select version(); version --- -- PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) (1 row) Config is: BINDIR = /usr/local/pgsql810/bin DOCDIR = /usr/local/pgsql810/doc INCLUDEDIR = /usr/local/pgsql810/include PKGINCLUDEDIR = /usr/local/pgsql810/include INCLUDEDIR-SERVER = /usr/local/pgsql810/include/server LIBDIR = /usr/local/pgsql810/lib PKGLIBDIR = /usr/local/pgsql810/lib LOCALEDIR = MANDIR = /usr/local/pgsql810/man SHAREDIR = /usr/local/pgsql810/share SYSCONFDIR = /usr/local/pgsql810/etc PGXS = /usr/local/pgsql810/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--enable-syslog' '--prefix=/usr/local/pgsql810' CC = gcc CPPFLAGS = -D_GNU_SOURCE CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,/usr/local/pgsql810/lib LDFLAGS_SL = LIBS = -lpgport -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm -lbsd VERSION = PostgreSQL 8.1.0 Log snippet as follows (serverlog is empty). postgres810 is 8.1.0, postgres is 8.0.2. Nov 6 16:02:09 thunder postgres810[5238]: [1-1] LOG: autovacuum: processing database tassiv Nov 6 16:03:09 thunder postgres810[5306]: [1-1] LOG: autovacuum: processing database bacula Nov 6 16:03:12 thunder postgres[1772]: [6-1] tassiv LOG: duration: 1539387.072 ms statement: COPY public.obs_v (x, y, imag, smag, sky, chi, sharp, iter, loc, obs_id, Nov 6 16:03:12 thunder postgres[1772]: [6-2] file_id, use, solve, star_id, mag) TO stdout; Nov 6 16:04:09 thunder postgres810[5359]: [1-1] LOG: autovacuum: processing database cpan Nov 6 16:05:09 thunder postgres[1772]: [7-1] tassiv LOG: duration: 98330.722 ms statement: COPY public.tycho2 (star_id, gsc, loc, bt, e_bt, vt, e_vt, prox) TO stdout; Nov 6 16:05:09 thunder postgres810[5418]: [1-1] LOG: autovacuum: processing database dspam Nov 6 16:05:15 thunder postgres810[1773]: [20-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index catalog_pkey for table catalog Nov 6 16:05:32 thunder postgres810[1773]: [21-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index color_groups_pkey for table color_groups Nov 6 16:05:32 thunder postgres810[1773]: [22-1] tassivNOTICE: ALTER TABLE / ADD UNIQUE will create implicit index files_name_key for table files Nov 6 16:05:32 thunder postgres810[1773]: [23-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index files_pkey for table files Nov 6 16:05:32 thunder postgres810[1773]: [24-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index groups_pkey for table groups Nov 6 16:05:32 thunder postgres810[1773]: [25-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index new_reference_loc_pkey for table new_reference_loc Nov 6 16:05:32 thunder postgres810[1773]: [26-1] tassivNOTICE: ALTER TABLE / ADD UNIQUE will create implicit index nights_night_key for table nights Nov 6 16:05:32 thunder postgres810[1773]: [27-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index nights_pkey for table nights Nov 6 16:05:32 thunder postgres810[1773]: [28-1] tassivNOTICE: ALTER TABLE / ADD UNIQUE will create implicit index obs_root_obs_id_key for table obs_root Nov 6 16:05:32 thunder postgres810[1773]: [29-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index pairs_pkey for table pairs Nov 6 16:05:32 thunder postgres810[1773]: [30-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index reference_ubvri_pkey for table reference_ubvri Nov 6 16:05:34 thunder postgres810[1773]: [31-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index sites_pkey for table sites Nov 6 16:05:34 thunder postgres810[1773]: [32-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index tycho2_pkey for table tycho2 Nov 6 16:05:55 thunder postgres810[1773]: [33-1] tassivNOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index zero_pair_pkey for table zero_pair Nov 6 16:06:10 thunder postgres810[5489]: [1-1] LOG: autovacuum: processing database template1 Nov 6 16:06:27 thunder postgres810[32258]: [1-1] LOG: server process (PID 1773) was terminated by signal 11 Nov 6 16:06:27 thunder postgres810[32258]: [2-1] LOG: terminating any other active server processes Nov 6 16:06:27 thunder postgres810[32258]: [3-1] LOG: all
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a different result from the 8.1 binaries? cheers andrew Robert Creager wrote: Hey all, I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a segmentation violation 1 hour into the operation. My plan is to re-do the dump/restore, and if it fails again, to re-compile with debug and cassert, and try to get a core. The command line was (8.1.0 is on port 5433): time pg_dumpall -c -v | psql -p 5433 -d template1 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] I can't get row type from tuple (SPI)
Hello I execute select anyrowfce(..) in plpgsql via exec_run_select I need to get inner row, but I can't find good way for it retval = SPI_getbinval(estate-eval_tuptable-vals[0], estate-eval_tuptable-tupdesc,1); rettype = SPI_gettypeid(estate-eval_tuptable-tupdesc,1); rettupdesc = lookup_rowtype_tupdesc(rettype,0); rettupdesc is ok, but when I try SPI_getbinval(retval, rettupdesc, ...) I kill backend. What I do wrong? What is optimal process to get first field in row, when this first field is row too. for example I need to way for value 1 in select select row(row(1,2,3)); = ((1,2,3)) Can I get inner tupdesc without lookup_rowtype_tupdesc? Thank you very much Pavel Stehule _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.1 RC1
Marc, Okay, I found an OpenSSL-0.9.7 and readline library. The IRIX 6.5 IP35 also passed with the OpenSSL and readline included. This is with the IRIX cc and not gcc. Ken On Mon, Oct 24, 2005 at 11:51:26AM -0300, Marc G. Fournier wrote: We have released a Release Candidate 1 of the upcoming 8.1 Release. With this beta, Tom has also put out the call for port reports, to round out our 'Supported Platforms' list: If you don't see your favorite platform already listed as tested for 8.1 at http://developer.postgresql.org/docs/postgres/supported-platforms.html then please give it a try and send in your results. We heavily encourage any, and all, to test this Beta out, to make sure we have weeded out as many bugs before release as possible ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.1 Beta 4
Marc, I just finished a build with the 8.1beta4 for IRIX 6.5 but without the nuances. We do not really use SGI other than in special circumstances but the regression test passed all tests: configure --without-readline using IRIX cc. Ken On Mon, Oct 24, 2005 at 11:51:26AM -0300, Marc G. Fournier wrote: In order to address some issues found with the Windows port, as well as GCC4, we have released a Beta 4 of the upcoming 8.1 Release. This Beta is meant to be a quick beta, baring any problems, with our first Release Candidate happening late this same week. With this beta, Tom has also put out the call for port reports, to round out our 'Supported Platforms' list: If you don't see your favorite platform already listed as tested for 8.1 at http://developer.postgresql.org/docs/postgres/supported-platforms.html then please give it a try and send in your results. We heavily encourage any, and all, to test this Beta out, to make sure we have weeded out as many bugs before release as possible ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pgInstaller 8.1 built
From: Marc G. Fournier Hiroshi; I think we're ready for the Japanese version whenever you're ready :-) Thanks! However, I have still left much work. I needed of several days. then, do my best. several days isn't a biggie ... that's one of the reasons why we left such a gap between bundle and announce, there are more and more 'packges' that have to be built :) Thank you for a great sound. I will do my best, though dishwashing is also contained in the busyness. In Dave, although there is busyness which uses a washing machine further, work is quick.:-) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] I can't get row type from tuple (SPI)
Pavel Stehule [EMAIL PROTECTED] writes: rettupdesc = lookup_rowtype_tupdesc(rettype,0); This is wrong --- if you don't know what typmod to use, *always* pass -1 not 0. (I suspect that rettype is RECORD and that -1 would have resulted in a NULL result.) It seems like SPI is missing a needed function: it should have an SPI_gettypmod to go along with SPI_gettypeid. This would probably give you the correct typmod to pass to lookup_rowtype_tupdesc here. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
When grilled further on (Sun, 06 Nov 2005 18:52:40 -0500), Andrew Dunstan [EMAIL PROTECTED] confessed: Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a different result from the 8.1 binaries? 8.0 was first. I've specified the correct full path now for the executables. Also, I've actually installed the shared libraries for the types and triggers that I use on that DB. I always seem to forget that :-( But, the table/index that it dies on is not using either the trigger or non native types, unless PG isn't getting the chance to emit that it's working on the next one before it goes out to lunch? The second reload died also. If the third dies (now that the type is in place), I'll do the re-compile and core. tassiv=# \d zero_pair Table public.zero_pair Column| Type | Modifiers --+-+--- pair_id | integer | not null group_id | integer | zero_v | real| default 0 zero_v_sigma | real| default 0 zero_i | real| default 0 zero_i_sigma | real| default 0 Indexes: zero_pair_pkey PRIMARY KEY, btree (pair_id) zero_pair_group_id btree (group_id) Foreign-key constraints: zero_pair_group_id_fkey FOREIGN KEY (group_id) REFERENCES color_groups(group_id) ON DELETE CASCADE zero_pair_pair_id_fkey FOREIGN KEY (pair_id) REFERENCES pairs(pair_id) ON DELETE CASCADE tassiv=# \d zero_pair_pkey Index public.zero_pair_pkey Column | Type -+- pair_id | integer primary key, btree, for table public.zero_pair Cheers, Rob -- 19:49:33 up 35 days, 12:24, 8 users, load average: 2.93, 2.51, 2.30 Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PG 8.1 supported platforms list: IRIX is MIA
On Sun, 6 Nov 2005, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: I had a colleague test for me on his IRIX (6.5?) MIPSPRO machine. The following regression tests fail: http://treehou.se/~finn/regression.diffs Hm, looks like strtod() has some bizarre behavior for input infinity on that machine (NOT just failing to recognize it, but doing something actively incorrect --- we've seen such bugs on Solaris). I had a success report from someone else on Friday, so maybe this problem is confined to specific IRIX versions? Perhaps. This was version 6.5.28 running on an Octane. Gavin ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
