[HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Hello, I miss some info in context: function's oid, function's argumenst and schema. Maybe: 199292 function public.foo(int, int, int) language plpgsql statement return line 10 or short version: 1229298 function public.foo 10 return which is easy parseable Best regards Pavel Stehule _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] vcbuild bison check
Attached patch adds a version check for bison when running the vc++ build. Shouldn't it be looking for 2.1 as well? 2.1 is the broken one. Exactly. So we should reject it. We do. The code as-is *only* accepts 1.875. Thus it rejects 2.1. //Magnus ---(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] cvsweb.cgi missing colors
The stylesheet (/css/cvsweb/cvsweb.css) is a 404, that's why. I don't really know my way around that box, so I don't know why it happened and what to fix, but that's what's broken. //Magnus -Original Message- From: [EMAIL PROTECTED] [mailto:pgsql-hackers- [EMAIL PROTECTED] On Behalf Of Andrew Dunstan Sent: Wednesday, October 04, 2006 1:30 AM To: PostgreSQL Hackers Subject: [HACKERS] cvsweb.cgi missing colors What has our cvsweb.cgi recently lost its colors? It has made it almost completely unusable. Example: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/ misc/postgresql.conf.sample.diff?r1=1.195;r2=1.196;f=h cheers andrew ---(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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] cvsweb.cgi missing colors
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 04 October 2006 08:36 To: Andrew Dunstan; PostgreSQL Hackers Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] cvsweb.cgi missing colors The stylesheet (/css/cvsweb/cvsweb.css) is a 404, that's why. I don't really know my way around that box, so I don't know why it happened and what to fix, but that's what's broken. Sorry, my bad - fixed now. Regards Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PG qsort vs. Solaris
So basically, glibc's qsort is bad enough that even a 10%-more-comparisons advantage doesn't save it. Do those numbers look very different if you have lots of columns or if you're sorting on something like an array or a ROW? Imho, that also is an argument for using our own qsort. It can be extended to deal with high comparison function cost directly. Thus I would opt to add a comparison function cost arg to qsort_arg iff we find scenarios where our qsort performs too bad. This cost can be used to switch to merge sort for very high cost values. Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Tsearch2 and Snowball
Simon, We have almost everything you listed in our TODO http://www.sai.msu.su/~megera/wiki/todo btw, there is gendict subdirectory, which help people to generate dictionaries (including snowball stemmers) for tsearch2. Oleg On Tue, 3 Oct 2006, Simon Riggs wrote: I'm looking at some of the code in contrib/tsearch2/snowball and see that the code there is *generated* code. The Snowball stemmer produces this C code in much the same way bison reads gram.y My understanding is that the Snowball code moves forwards regularly and there are many other stemmers we could be including with the distribution. Snowball has a BSD licence: http://snowball.tartarus.org/license.php Would it be possible to include the Snowball source directly and allow its execution to be part of the make process for tsearch2? Or have configure check for Snowball at make time? At the very least it would be good to have a Readme file explaining how to modify the Snowball stemmer and regenerate for tsearch2. That would then encourage people to improve the stemmers, as well as allow us to include French and Spanish versions etc.. Perhaps we should ask translators to provide stop word lists for their languages. It seems a shame to have docs in so many languages, but no language capability for Tsearch2. Also, why do we have another crc32 implementation in there? Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] workaround for buggy strtod is not necessary
Bruce Momjian wrote: Zdenek Kotala wrote: Solaris had broken strtod function when parse Inf and Nan. See solaris.h. This bug has been fixed for all current versions of Solaris ( 8, 9, 10). See http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-62-1searchclause=108993-62 http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-34-1searchclause=112874-34 Workaround is not necessary now, but I'm not sure if workaround removing is good idea. There are some possible variants: 1) keep workaround in the code for compatibility with unpatched system and adjust comment in solaris.h 2) remove workaround and mention required Solaris patch in the Solaris.FAQ document 3) add some test into configure script and use workaround only on unpatched system. (It should be nightmare for packagers) #1. What do you want to change about the existing comment? /* * Many versions of Solaris have broken strtod() --- see bug #4751182. * For the moment we just assume they all do; it's probably not worth * the trouble to add a configure test for this. */ /* Many versions of Solaris had broken strtod() -- see bug #4751182. Now, it is fixed in recent versions of Solaris (8 and above -- see patch 108993-62 and 112874-34). However, there should be many unpatched system. For the moment we just assume they all do; it's probably not worth the trouble to add a configure test for this. */ It is only update that it is fixed and why workaround is not removed. Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Digging gram.y
In gram.y
Typename: SimpleTypename opt_array_bounds
{
$$ = $1;
$$-arrayBounds = $2;
}
| SETOF SimpleTypename opt_array_bounds
{
$$ = $2;
$$-arrayBounds = $3;
$$-setof = TRUE;
}
Typename is a generic name of type and it used in many places in gram.c, but
AFAIK the single place with SETOF is a function's RETURNS declaration. So there
is many checks about SETOF. May I eliminate SETOF from Typename and leave it
only for RETURNS?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgindent has been run
On Tue, Oct 03, 2006 at 08:26:36PM -0400, Bruce Momjian wrote: I have run pgindent for 8.2. Is there a way to make pgindent skip a directory? It seems it has changed all expected file in ecpg's regression suite. So we see a lot of differences now. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] timestamptz alias
Hi, Tom, Tom Lane wrote: Here's a small patch that adds an appropriate explanation. If we're going to document these aliases, what of float4, float8, and bool? Also, although the docs mention int2/int4/int8, it's more or less left to the reader's imagination to deduce what they are. Perhaps it'd be better to provide a small table of recognized type aliases, rather than inserting equivalent notes into three or four places. It's not only about documenting the pure existence of the aliases (which was already documented in the table on the datatype TOC page), it's also about telling the user which of the names are the ones to avoid, and the reasons to do so. HTH, Markus -- Markus Schaber | Logical TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org signature.asc Description: OpenPGP digital signature
Re: [HACKERS] scripts/common.c minor memory leak
On Tue, Oct 03, 2006 at 05:27:31PM -0400, Andrew Dunstan wrote: It is surely not the only memory leak. We know there are some and in most cases (like this) they aren't worth the trouble to clean up. If it were used in psql or the backend I'd be worried, but it isn't, so I'm not. Ofcourse not. You don't see any messages about the other 100 leaks found because I figure they're not worth the effort. This function is used widely enough and a simple enough fix that I figured I might be worth fixing. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] tsearch2 error msg
Hi, Tom, Tom Lane wrote: No, it should be something like syntax error in tsearch query: contents of string since it's not always the case that you know exactly what string got fed to to_tsquery(). I agree. It's also possible that you have more than one tsearch expression in the query (e. G. by joining different tables), so that will help further. HTH, Markus -- Markus Schaber | Logical TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org signature.asc Description: OpenPGP digital signature
Re: [HACKERS] buildfarm failures in ECPG-Check
On Tue, Oct 03, 2006 at 06:54:15PM -0400, Tom Lane wrote: Looks like blow-back from the recent change in default GUC parameters. However, I think update the expected output is the wrong answer, I completely agree and thus changed this example to only show variable settings of variable the program sets itself. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] [PATCHES] vcbuild bison check
Magnus Hagander wrote: Attached patch adds a version check for bison when running the vc++ build. Shouldn't it be looking for 2.1 as well? 2.1 is the broken one. Exactly. So we should reject it. We do. The code as-is *only* accepts 1.875. Thus it rejects 2.1. I think Tom's point is that we should reject only 2.1. Isn't that the only version that fails? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pgindent has been run
Michael Meskes wrote: On Tue, Oct 03, 2006 at 08:26:36PM -0400, Bruce Momjian wrote: I have run pgindent for 8.2. Is there a way to make pgindent skip a directory? It seems it has changed all expected file in ecpg's regression suite. So we see a lot of differences now. Sure a directory can be skipped. I am confused how it could change expected files because it only formats C files. Seems I need to run the ecpg regressions now as part of my normal checkin process. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgindent has been run
On Wed, Oct 04, 2006 at 06:15:31AM -0400, Bruce Momjian wrote: Michael Meskes wrote: Is there a way to make pgindent skip a directory? It seems it has changed all expected file in ecpg's regression suite. So we see a lot of differences now. Sure a directory can be skipped. I am confused how it could change expected files because it only formats C files. The .c files that are produced by the ecpg precompiler are in the expected/ directory as well. Instead of skipping this directory we could also rename them from *.c to *.source or similar such that pgindent will not touch them. Joachim ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Further Block B-tree thoughts
Just to let everyone know, I'm continuing work on the Block B-tree idea discussed earlier. The current plan is to have a (compressed) bitmap of offsets attached to index tuples, to allow vacuuming. For example, if we have a heap like this: 2 4 6 8 - 10 12 14 16 5 - 18 20 where dashes represent page boundaries, the corresponding index would look like: low key - heap blk no (offsets) 2 - 1 (1,2) 5 - 2 (5) 6 - 1 (3,4) 10 - 2 (1,2,3,4) 18 - 3 (1,2) So each index tuple points to a group of tuples that are located on the same page. The grouped tuples have keys in the range this index key - next index key, and there's no other tuples with a key in that range. On index page boundaries, the high key of the page can be used instead of the next index key to simplify insertion and scanning. When scanning, index quals need to be rechecked after fetching the heap tuples, unless the index tuple pointed to just one heap tuple, or we're doing a range scan and both the min and max key of the group are within the range. And to do a regular ordered index scan, tuples within a group need to be sorted. The current B-tree is a special case of this design, where each index tuple points to a single heap tuple. At first I thought this would be a new index access method, but it now seems that it makes more sense to integrate this with the normal B-tree, assuming that the behavior and performance is the same when all index tuples point to single heap tuples. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(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
[HACKERS] SQL:2003 Statistical functions - What are they?
I'm not sure this is the right group to ask this. I see that the 8.2 notes say all SQL:2003 statistical functions are implemented in 8.2, but I couldn't find a listing for those anywhere I looked. For those who are clueless like me, can someone provide a listing of what these functions are? Thanks, Regina - The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Zdenek Kotala wrote: Alvaro Herrera wrote: What's global? A maybe-useful flag would be telling that a table is shared. Is that it? Mind you, it's not useful to me because I know which tables are shared, but I guess for someone not so familiar with the catalogs it could have some use. Global means share table stored in global directory :-). Ok I change it. There is new version of catalogs overview patch. This version add only one column into overview table which contains Oid/Filename for each catalog table. Oid information is important if someone need make relation with filename on disk and related catalog table. In this column shared table are marked as well. Other information like bootstrap and with-oids are really useless and they is not mentioned. Zdenek Index: doc/src/sgml/catalogs.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v retrieving revision 2.134 diff -c -r2.134 catalogs.sgml *** doc/src/sgml/catalogs.sgml 22 Sep 2006 23:20:13 - 2.134 --- doc/src/sgml/catalogs.sgml 4 Oct 2006 12:17:49 - *** *** 33,47 Most system catalogs are copied from the template database during database creation and are thereafter database-specific. A few catalogs are physically shared across all databases in a cluster; !these are noted in the descriptions of the individual catalogs. /para table id=catalog-table titleSystem Catalogs/title !tgroup cols=2 thead row entryCatalog Name/entry entryPurpose/entry /row --- 33,49 Most system catalogs are copied from the template database during database creation and are thereafter database-specific. A few catalogs are physically shared across all databases in a cluster; !these are noted in the Oid/Filename column and in the descriptions !of the individual catalogs. /para table id=catalog-table titleSystem Catalogs/title !tgroup cols=3 thead row + entryOid/Filename/entry entryCatalog Name/entry entryPurpose/entry /row *** *** 49,214 --- 51,249 tbody row + entry2600/entry entrylink linkend=catalog-pg-aggregatestructnamepg_aggregate/structname/link/entry entryaggregate functions/entry /row row + entry2601/entry entrylink linkend=catalog-pg-amstructnamepg_am/structname/link/entry entryindex access methods/entry /row row + entry2602/entry entrylink linkend=catalog-pg-amopstructnamepg_amop/structname/link/entry entryaccess method operators/entry /row row + entry2603/entry entrylink linkend=catalog-pg-amprocstructnamepg_amproc/structname/link/entry entryaccess method support procedures/entry /row row + entry2604/entry entrylink linkend=catalog-pg-attrdefstructnamepg_attrdef/structname/link/entry entrycolumn default values/entry /row row + entry1249/entry entrylink linkend=catalog-pg-attributestructnamepg_attribute/structname/link/entry entrytable columns (quoteattributes/quote)/entry /row row + entry1260 (shared)/entry entrylink linkend=catalog-pg-authidstructnamepg_authid/structname/link/entry entryauthorization identifiers (roles)/entry /row row + entry1261 (shared)/entry entrylink linkend=catalog-pg-auth-membersstructnamepg_auth_members/structname/link/entry entryauthorization identifier membership relationships/entry /row row + entry1248/entry entrylink linkend=catalog-pg-autovacuumstructnamepg_autovacuum/structname/link/entry entryper-relation autovacuum configuration parameters/entry /row row + entry2605/entry entrylink linkend=catalog-pg-caststructnamepg_cast/structname/link/entry entrycasts (data type conversions)/entry /row row + entry1259/entry entrylink linkend=catalog-pg-classstructnamepg_class/structname/link/entry entrytables, indexes, sequences, views (quoterelations/quote)/entry /row row + entry2606/entry entrylink linkend=catalog-pg-constraintstructnamepg_constraint/structname/link/entry entrycheck constraints, unique constraints, primary key constraints, foreign key constraints/entry /row row + entry2607/entry entrylink linkend=catalog-pg-conversionstructnamepg_conversion/structname/link/entry entryencoding conversion information/entry /row row + entry1262 (shared)/entry entrylink linkend=catalog-pg-databasestructnamepg_database/structname/link/entry entrydatabases within this database cluster/entry
Re: [HACKERS] [PATCHES] MSVC build broken (again)
Would it be possible to move the whole crtdefs.h block into win32.h? Nope, it needs to go before stdio.h and friends, unfortunatly. OK, patch committed as-is then. The whole thing still looks awfully icky though, particularly the way pg_config_os.h is included in one place for WIN32 and a different place everywhere else. Would it make sense to split win32.h into two files, one that's included in the normal pg_config_os.h place and one included after the system includes? I've been looking at doing this before, but never got around to it. It's a bit hairy, so it's definitly not something we want to do during beta, though. But maybe for 8.3. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] vcbuild bison check
2.1 is the broken one. Exactly. So we should reject it. We do. The code as-is *only* accepts 1.875. Thus it rejects 2.1. I think Tom's point is that we should reject only 2.1. Isn't that the only version that fails? Not entirely sure. I beleive there were older versions that don't work as well... And you can't expect lots of older versions around - I'm sure *at least* 99% of the ppl who are building withthis will download bison specifically for this. And given that, they're going to get the latest by default, or 1.875 if they read the (currently being written) README. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] vcbuild bison check
And given that, they're going to get the latest by default, or 1.875 if they read the (currently being written) README. The point was, that = 2.2 won't be allowed when it comes out for win32, even if it should work. Right. So I'd update it once we see a working version other than 1.875. //mha ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SQL:2003 Statistical functions - What are they?
On 10/4/06, Obe, Regina [EMAIL PROTECTED] wrote: I'm not sure this is the right group to ask this. I see that the 8.2 notes say all SQL:2003 statistical functions are implemented in 8.2, but I couldn't find a listing for those anywhere I looked. For those who are clueless like me, can someone provide a listing of what these functions are? look in the aggregate functions (9.15) section of the developers documentation. http://developer.postgresql.org/pgdocs/postgres/index.html However, the release notes mentioned array improvements and I didn't see anything in the documentation, are these functions listed somewhere? merlin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] timestamptz alias
Markus Schaber wrote: It's not only about documenting the pure existence of the aliases (which was already documented in the table on the datatype TOC page), it's also about telling the user which of the names are the ones to avoid, and the reasons to do so. *blink* Why do any need to be avoided? What you use is a matter of taste, and your organisation's coding standards. From a purely technical POV I don't see any reason to avoid using either the canonical type names or the various aliases. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Zdenek Kotala [EMAIL PROTECTED] writes: There is new version of catalogs overview patch. This version add only one column into overview table which contains Oid/Filename for each catalog table. Oid information is important if someone need make relation with filename on disk and related catalog table. I still say this is just confusing clutter. The proposed patch even goes so far as to give the OID pride of place as the most important item you could possibly want to know about a catalog, which is surely silly. People who actually want to know this information can look into the pg_class catalog, which has the advantages of being complete (eg, it covers indexes too), guaranteed up-to-date, and easily program-readable. I really do not see the value of putting it in the sgml docs. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] vcbuild bison check
Magnus Hagander [EMAIL PROTECTED] writes: The point was, that = 2.2 won't be allowed when it comes out for win32, even if it should work. Right. So I'd update it once we see a working version other than 1.875. No, we should ship it that way to start with. Otherwise we're going to get caught with no released source code that will allow 2.2. A look at ftp.gnu.org says that 2.2 was released 19-May-2006 and 2.3 was released 05-Jun-2006. So it's not like these versions are fresh off the boat. I think it's safe to assume that someone will bother to compile them for Windows, probably sooner not later. We should be making sure our code works with them, rather than making sure it doesn't. regards, tom lane ---(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] [PATCHES] vcbuild bison check
The point was, that = 2.2 won't be allowed when it comes out for win32, even if it should work. Right. So I'd update it once we see a working version other than 1.875. No, we should ship it that way to start with. Otherwise we're going to get caught with no released source code that will allow 2.2. A look at ftp.gnu.org says that 2.2 was released 19-May-2006 and 2.3 was released 05-Jun-2006. So it's not like these versions are fresh off the boat. I think it's safe to assume that someone will bother to compile them for Windows, probably sooner not later. We should be making sure our code works with them, rather than making sure it doesn't. Ok. So what you want is something that checks that it's =1.875 but specifically not 2.1? Might be a while before I can submit an updated patch for that, may need to rewrite the whole script in perl to do that :-( .bat files are horribly limited in what they can do. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] vcbuild bison check
Magnus Hagander [EMAIL PROTECTED] writes: I think Tom's point is that we should reject only 2.1. Isn't that the only version that fails? Not entirely sure. I beleive there were older versions that don't work as well... My recollection is that the version immediately prior to 1.875 was actively broken, and that versions much before that fail to cope with the current size of our grammar. What I see in ftp.gnu.org since 1.875 are 2.0, 2.1, 2.2, 2.3. We do not know at this point whether the extra-semicolon bug is present in 2.0 or only 2.1 ... but I will download them and find out. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] vcbuild bison check
Magnus Hagander [EMAIL PROTECTED] writes: Ok. So what you want is something that checks that it's =1.875 but specifically not 2.1? Let me finish investigating the 2.x series and get back to you on that. Might be a while before I can submit an updated patch for that, may need to rewrite the whole script in perl to do that :-( .bat files are horribly limited in what they can do. I see no big reason for hurry here, as long as it's in before RC1. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] vcbuild bison check
I wrote: Let me finish investigating the 2.x series and get back to you on that. 2.1 indeed seems to be the only version that emits the busted semicolon. I found that 2.2 and 2.3 both fail one of their make check tests on my machine --- if that's widespread it might explain a slow uptake rate for these versions :-(. But the failure is in one of the GLR tests and shouldn't affect us. All four 2.x versions produce gram.c files that compile and pass regression for me. So I'd vote for allow 1.875 and up, except 2.1 specifically. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] timestamptz alias
Hi, Andrew, Andrew Dunstan wrote: It's not only about documenting the pure existence of the aliases (which was already documented in the table on the datatype TOC page), it's also about telling the user which of the names are the ones to avoid, and the reasons to do so. *blink* Why do any need to be avoided? What you use is a matter of taste, and your organisation's coding standards. From a purely technical POV I don't see any reason to avoid using either the canonical type names or the various aliases. At least compatibility with the SQL standard, as well as with other Databases might be a reason. Using pure timestamp may lead human readers to be confused, because it has both meanings with and without timezone historically, this might be a reason to prefer the timestamp with[out] time zone wording. HTH, Markus -- Markus Schaber | Logical TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org signature.asc Description: OpenPGP digital signature
Re: [HACKERS] [PATCHES] vcbuild bison check
Ok. So what you want is something that checks that it's =1.875 but specifically not 2.1? Might be a while before I can submit an updated patch for that, may need to rewrite the whole script in perl to do that :-( .bat files are horribly limited in what they can do. Since we are on NT or higher you could use extensions: IF %bversion% GEQ 1.875 IF %bversion% NEQ 2.1 goto use_bison http://www.robvanderwoude.com/ntif.html (even in .bat files) to avoid converting to perl. sorry, haven't looked at the file so needs adaption Thank you for the work Andreas ---(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] [PATCHES] vcbuild bison check
Ok. So what you want is something that checks that it's =1.875 but specifically not 2.1? Might be a while before I can submit an updated patch for that, may need to rewrite the whole script in perl to do that :-( .bat files are horribly limited in what they can do. Since we are on NT or higher you could use extensions: IF %bversion% GEQ 1.875 IF %bversion% NEQ 2.1 goto use_bison http://www.robvanderwoude.com/ntif.html I thought that only worked if your locale was set to something that has dot as decimal separator. Mine has comma, as have many others... //Magnus ---(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] [PATCHES] vcbuild bison check
-Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 6:01 PM To: Zeugswetter Andreas ADI SD Cc: pgsql-hackers@postgresql.org Subject: RE: [HACKERS] [PATCHES] vcbuild bison check Ok. So what you want is something that checks that it's =1.875 but specifically not 2.1? Might be a while before I can submit an updated patch for that, may need to rewrite the whole script in perl to do that :-( .bat files are horribly limited in what they can do. Since we are on NT or higher you could use extensions: IF %bversion% GEQ 1.875 IF %bversion% NEQ 2.1 goto use_bison http://www.robvanderwoude.com/ntif.html I thought that only worked if your locale was set to something that has dot as decimal separator. Mine has comma, as have many others... Um, I think it does a string compare because point or comma is no decimal digit, but that would imho also be sufficient. My locale is German, so my decimal sep should also be a comma, and it worked for the mentioned versions. Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] vcbuild bison check
Magnus Hagander wrote: Ok. So what you want is something that checks that it's =1.875 but specifically not 2.1? Might be a while before I can submit an updated patch for that, may need to rewrite the whole script in perl to do that :-( .bat files are horribly limited in what they can do. Since we are on NT or higher you could use extensions: IF %bversion% GEQ 1.875 IF %bversion% NEQ 2.1 goto use_bison http://www.robvanderwoude.com/ntif.html I thought that only worked if your locale was set to something that has dot as decimal separator. Mine has comma, as have many others... Won't it just do a string comparison, then? That's probably good enough in this instance. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] vcbuild bison check
And given that, they're going to get the latest by default, or 1.875 if they read the (currently being written) README. The point was, that = 2.2 won't be allowed when it comes out for win32, even if it should work. Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Pavel Stehule [EMAIL PROTECTED] writes: I miss some info in context: function's oid, function's argumenst and schema. Maybe: 199292 function public.foo(int, int, int) language plpgsql statement return line 10 Putting the OID there is a seriously awful idea, not least because it would make it impossible to have stable regression-test outputs. I'm not really convinced that we need more than the function name. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Another aspect of set_ps_display ()
We were just analyzing some more OProfile and ltrace data against
Postgres 8.2Beta1 and we noticed a number of calls as follows:
strlen(postgres: tpc tpc 192.168.1.200(...)= 58
memset(0xb6b2, '\000', 2344) = 0xb6b2
We have tracked this down to the following code in the set_ps_display ()
function:
#ifdef PS_USE_CLOBBER_ARGV
{
int buflen;
/* pad unused memory */
buflen = strlen(ps_buffer);
MemSet(ps_buffer + buflen, PS_PADDING, ps_buffer_size - buflen);
}
#endif /* PS_USE_CLOBBER_ARGV */
If set_ps_display () moves to use the strlcpy () function call, this
code might be redundant. Even if the StrNCpy () call is kept, this code
may still be redundant as StrNCpy () will zero fill the ps_buffer.
A MemSet () call on the ps_buffer has to be added to the init_ps_display
() function, if this code is removed to clear the buffer before use.
David
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Digging gram.y
Teodor Sigaev [EMAIL PROTECTED] writes: May I eliminate SETOF from Typename and leave it only for RETURNS? Why do you want to? I think the reason it's in Typename is the assumption that in future we would try to extend the applicability of SETOF, not restrict it. For instance I can see reasons for wanting SETOF on a function's input parameter (to pass it a whole table or select result in one call). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] qsort_arg needed for msvc build
Magnus Hagander [EMAIL PROTECTED] writes: See attached patch. Grumble. That's going to be a continuing maintenance pain, isn't it? We need to find a way to extract the list from the src/port Makefile. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from
Hi, Tom, Tom Lane wrote: I miss some info in context: function's oid, function's argumenst and schema. Maybe: 199292 function public.foo(int, int, int) language plpgsql statement return line 10 Putting the OID there is a seriously awful idea, not least because it would make it impossible to have stable regression-test outputs. I'm not really convinced that we need more than the function name. I also think that the OID will hurt here, but schema and argument types may be useful in some corner cases. Markus -- Markus Schaber | Logical TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org signature.asc Description: OpenPGP digital signature
Re: [HACKERS] [PATCHES] qsort_arg needed for msvc build
See attached patch. Grumble. That's going to be a continuing maintenance pain, isn't it? We need to find a way to extract the list from the src/port Makefile. Well, it's platform dependent as it's set from configure, no? I guess we could pull the use on all platforms set, and then just append win32 specific ones, that should help a bit? If there is such a list (don't have the code around right now) to read from. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Digging gram.y
Why do you want to? Just simplify. For instance I can see reasons for wanting SETOF on a function's input parameter (to pass it a whole table or select result in one call). I see. But Typename is used for table's definition for example. I can't imagine column setof text. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] qsort_arg needed for msvc build
Magnus Hagander [EMAIL PROTECTED] writes: I guess we could pull the use on all platforms set, and then just append win32 specific ones, that should help a bit? If there is such a list (don't have the code around right now) to read from. That would probably help. Currently the all platforms list is in Makefile.global.in (part of the setup of $(LIBOBJ)), which is itself a pretty crufty thing. Not sure where better to put it though. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Digging gram.y
Teodor Sigaev [EMAIL PROTECTED] writes: Why do you want to? Just simplify. I think you'd just be moving the complexity somewhere else. regards, tom lane ---(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] Faster StrNCpy
ZA == Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes: ZA Yes, but it obviously does not in some ports, and that was the ZA main problem as I interpreted it. strncpy is part of POSIX; I highly doubt anyone gets it wrong. Getting sane semantics from it does require manually writing null to the last location in the buffer. If you need the null byte padding feature of strncpy, it seems a bit silly to replace it with strlcpy. Particularly if the only reason is performance. Down that road lies pglibc. /Benny ---(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] [PATCHES] DOC: catalog.sgml
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: There is new version of catalogs overview patch. This version add only one column into overview table which contains Oid/Filename for each catalog table. Oid information is important if someone need make relation with filename on disk and related catalog table. I still say this is just confusing clutter. The proposed patch even goes so far as to give the OID pride of place as the most important item you could possibly want to know about a catalog, which is surely silly. You have right that OID is not important information in many cases, but how I said It is useful when you want know relation between filename and catalog table. People who actually want to know this information can look into the pg_class catalog, which has the advantages of being complete (eg, it covers indexes too), guaranteed up-to-date, and easily program-readable. I really do not see the value of putting it in the sgml docs. You can look into pg_class catalog only if database is running. If you have some data corruption problem, OID should help during recovery. But you have right, that pg_class have complex information and who want to play with datafiles, he must know more than OID. OK, thanks for response, forget to this patch Zdenek ---(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
[HACKERS] Updated version of FAQ_Solaris
I updated FAQ_Solaris. I added new information related to Solaris 10, rewrote optimalization hints and add information about dtrace. I talked with Peter about Current maintainer role, and he said that this information says anything and should be deleted. Please, let me know your comments Zdenek *** pgsql-061004/doc/FAQ_Solaris Tue Oct 3 01:01:17 2006 --- pgsql-060829/doc/FAQ_Solaris Wed Oct 4 20:11:35 2006 *** *** 3,13 Sun Solaris specific to be read in conjunction with the installation instructions ! last updated:$Date: 2006/10/02 23:01:17 $ - current maintainer: Peter Eisentraut [EMAIL PROTECTED] - Contents: 1) What tools do I need to build and install PostgreSQL on Solaris? --- 3,11 Sun Solaris specific to be read in conjunction with the installation instructions ! last updated:$Date: 2003/10/09 17:11:13 $ Contents: 1) What tools do I need to build and install PostgreSQL on Solaris? *** *** 15,20 --- 13,22 3) Why does configure complain about a failed test program? 4) Why does my 64-bit build sometimes crash? 5) How can I compile for optimum performance? + 6) How to compile PostgreSQL with Sun Studio? + 7) Where I can download prepared Solaris packages? + 8) How to tune PostgreSQL and Solaris for best performance? + 9) Can I use dtrace for tracing PostgreSQL? 1) What tools do I need to build and install PostgreSQL on Solaris? *** *** 23,40 - GNU zip (for installing the documentation) - GNU make - GNU readline library (optional) ! - GCC (if you don't have Sun's compiler) ! If you like Solaris packages, you can find these tools here: ! http://www.sunfreeware.com If you prefer sources, look here: http://www.gnu.org/order/ftp.html ! You can build with either GCC or Sun's compiler suite. We have heard ! reports of problems when using gcc 2.95.1; gcc 2.95.3 or later is ! recommended. If you are using Sun's compiler, be careful *not* to ! select /usr/ucb/cc; use /opt/SUNWspro/bin/cc. 2) Why do I get problems when building with OpenSSL support? --- 25,51 - GNU zip (for installing the documentation) - GNU make - GNU readline library (optional) ! - Sun Studio CC or GCC ! You can download Sun Studio from: ! http://developers.sun.com/prodtech/cc/downloads/index.jsp + Many of GNU tools are integrated into the Solaris 10 or they are + present on the Solaris companion CD. + + If you like packages for older version of Solaris, you can find these + tools here: + http://www.sunfreeware.com or http://www.blastwave.org + If you prefer sources, look here: http://www.gnu.org/order/ftp.html ! You can build with either GCC or Sun's compiler suite. For better ! code optimalization Sun's compiler is strongly recommended on the ! SPARC architecture. We have heard reports of problems when using ! gcc 2.95.1; gcc 2.95.3 or later is recommended. If you are using ! Sun's compiler, be careful *not* to select /usr/ucb/cc; ! use /opt/SUNWspro/bin/cc. 2) Why do I get problems when building with OpenSSL support? *** *** 53,67 Upgrading your OpenSSL installation to version 0.9.6a fixes this problem. 3) Why does configure complain about a failed test program? This is probably a case of the run-time linker being unable to find ! libz or some other non-standard library, such as libssl. To point it ! to the right location, set the LD_LIBRARY_PATH environment variable, ! e.g., ! LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib export LD_LIBRARY_PATH and restart configure. You will also have to keep this setting --- 64,80 Upgrading your OpenSSL installation to version 0.9.6a fixes this problem. + Solaris 9 and above already newer version of OpenSSL. + 3) Why does configure complain about a failed test program? This is probably a case of the run-time linker being unable to find ! some library. On solaris 8 and older it should be libz or some other ! non-standard library, such as libssl. To point it to the right location, ! set the LD_LIBRARY_PATH environment variable, e.g., ! LD_LIBRARY_PATH=/usr/sfw/lib:/opt/sfw/lib:/usr/local/lib export LD_LIBRARY_PATH and restart configure. You will also have to keep this setting *** *** 88,90 --- 101,177 does not matter.) Then build as usual. + + + 5) How can I compile for optimum performance? + + On SPARC architecture Sun Studio is strongly recommended for compilation. + Try using -xO5 optimalization flag to generate significantly faster binaries. + Do not use any flags which modify behavior of floating point operations and + errno processing (e.g. -fast). These flags should raise some nonstandard + PostgreSQL behavior for example in
[HACKERS] Netflix Prize data
I signed up for the Netflix Prize. (www.netflixprize.com) and downloaded their data and have imported it into PostgreSQL. Here is how I created the table: Table public.ratings Column | Type | Modifiers +-+--- item | integer | client | integer | rating | integer | rdate | text| Indexes: ratings_client btree (client) ratings_item btree (item) [EMAIL PROTECTED]:~/netflix$ time psql netflix -c select count(*) from ratings count --- 100480507 (1 row) real2m6.270s user0m0.004s sys 0m0.005s The one thing I notice is that it is REAL slow. I know it is, in fact, 100 million records, but I don't think PostgreSQL is usually slow like this. I'm going to check with some other machines to see if there is a problem with my test machine or if something is wierd about PostgreSQL and large numbers of rows. I tried to cluster the data along a particular index but had to cancel it after 3 hours. I'm using 8.1.4. The rdate field looks something like: 2005-09-06 So, the raw data is 23 bytes, the date string will probably be rounded up to 12 bytes, that's 24 bytes per row of data. What is the overhead per variable? per row? Is there any advantage to using varchar(10) over text ? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pgindent has been run
Joachim Wieland wrote: On Wed, Oct 04, 2006 at 06:15:31AM -0400, Bruce Momjian wrote: Michael Meskes wrote: Is there a way to make pgindent skip a directory? It seems it has changed all expected file in ecpg's regression suite. So we see a lot of differences now. Sure a directory can be skipped. I am confused how it could change expected files because it only formats C files. The .c files that are produced by the ecpg precompiler are in the expected/ directory as well. Instead of skipping this directory we could also rename them from *.c to *.source or similar such that pgindent will not touch them. I have updated the pgindent script to skip the ecpg regression expected directory: find . -name '*.[ch]' -type f -print | egrep -v '/s_lock.h|src/interfaces/ecpg/test/expected/' | xargs -n100 pgindent That will prevent it from being changed by pgindent in the future. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Netflix Prize data
Mark, On 10/4/06 1:43 PM, Mark Woodward [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~/netflix$ time psql netflix -c select count(*) from ratings count --- 100480507 (1 row) real2m6.270s user0m0.004s sys 0m0.005s I think you are getting about 40MB/s on your sequential scan of about 5GB of heap data in this case. I calculate the size of the data as: 3 Integers (12 bytes), one text date field (10 bytes ?) and tuple overhead (24 bytes) = 46 bytes per row 100 million rows x 46 bytes / row = 4.6 Gbytes - Luke ---(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] Netflix Prize data
Mark Woodward [EMAIL PROTECTED] writes: The one thing I notice is that it is REAL slow. How fast is your disk? Counting on my fingers, I estimate you are scanning the table at about 47MB/sec, which might or might not be disk-limited... I'm using 8.1.4. The rdate field looks something like: 2005-09-06 So why aren't you storing it as type date? regards, tom lane ---(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] SQL:2003 Statistical functions - What are they?
Merlin Moncure wrote: On 10/4/06, Obe, Regina [EMAIL PROTECTED] wrote: I'm not sure this is the right group to ask this. I see that the 8.2 notes say all SQL:2003 statistical functions are implemented in 8.2, but I couldn't find a listing for those anywhere I looked. For those who are clueless like me, can someone provide a listing of what these functions are? look in the aggregate functions (9.15) section of the developers documentation. http://developer.postgresql.org/pgdocs/postgres/index.html However, the release notes mentioned array improvements and I didn't see anything in the documentation, are these functions listed somewhere? From release notes: listitem para Add SQL2003-standard statistical aggregates (Sergey Koposov) /para para New functions: functionregr_intercept()/, functionregr_slope()/, functionregr_r2()/, functioncorr()/, functioncovar_samp()/, functioncovar_pop()/, functionregr_avgx()/, functionregr_avgy()/, functionregr_sxy()/, functionregr_sxx()/, functionregr_syy()/, functionregr_count()/. /para /listitem -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Netflix Prize data
Mark Woodward [EMAIL PROTECTED] writes: I'm using 8.1.4. The rdate field looks something like: 2005-09-06 So, the raw data is 23 bytes, the date string will probably be rounded up to 12 bytes, that's 24 bytes per row of data. What is the overhead per variable? per row? Is there any advantage to using varchar(10) over text ? I'll second the use a date comment. But to answer the questions, text and varchar are handled identically in almost every respect. The overhead per variable width field (like text or varchar) is 4 bytes. The overhead per row depends on a few factors, but figure 28 bytes. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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] PL/pgSQL Todo, better information in errcontext from plpgsql
Pavel Stehule [EMAIL PROTECTED] writes: I miss some info in context: function's oid, function's argumenst and schema. Maybe: 199292 function public.foo(int, int, int) language plpgsql statement return line 10 Putting the OID there is a seriously awful idea, not least because it would make it impossible to have stable regression-test outputs. I'm not really convinced that we need more than the function name. regards, tom lane it's strong argument, but it's true. I didn't think about it. Without fid I am not able identify function. regards Pavel Stehule _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ ---(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] 8.2beta1 failure on IRIX
On Sun, 1 Oct 2006, Tom Lane wrote:
Does this version of the patch address your concerns.
Some searching of the net shows that this has been reported before. Once in
the beta for 8.1 and again in January as bug #2192 (It looks like a patch
was included then but wasn't applied).
It seems like only certain versions of IRIX have this problem but I don't
know how common it is or what versions don't have the bug. Unless we want
to drop IRIX from the list of supported platforms we should apply one of the
fixes.
[EMAIL PROTECTED] writes:
I'm getting some failures in the regression tests on 8.2beta1 on IRIX.
It looks like IRIX (or at least some versions) has a broken strtod.
The float4 and float8 tests fail, I've attached a patch to
tools/adt/float.c that fixes the problem along with the regression output.
That patch is pretty seriously broken (not only because it's not ifdef'd
to apply only on the platform that needs it, but because it'll do the
wrong thing with infinityinity). But what I'm really wondering is why
we've not heard of this before? That code hasn't been changed in quite
some time.
regards, tom lane
Index: backend/utils/adt/float.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/float.c,v
retrieving revision 1.128
diff -c -r1.128 float.c
*** backend/utils/adt/float.c 28 Jul 2006 18:33:04 - 1.128
--- backend/utils/adt/float.c 4 Oct 2006 21:16:20 -
***
*** 327,332
--- 327,347
}
#endif /* HAVE_BUGGY_SOLARIS_STRTOD */
+ #ifdef HAVE_BUGGY_IRIX_STRTOD
+ if(endptr != num pg_strncasecmp(endptr,inity,5)==0
+ endptr - num =4
+ (pg_strncasecmp(num,infinity,8)==0 ||
+ pg_strncasecmp(num,-infinity,9)==0 ) )
+ {
+ /**
+ *
+ * Some versions of strtod (IRIX) stop
+ * parsing after inf and leave endptr as inity
+ */
+ endptr+=5;
+ }
+ #endif
+
/* skip trailing whitespace */
while (*endptr != '\0' isspace((unsigned char) *endptr))
endptr++;
***
*** 344,349
--- 359,377
*/
if (!isinf(val))
CheckFloat4Val(val);
+ #ifdef HAVE_BUGGY_IRIX_STRTOD
+ else {
+ /**
+ * If val is infinity, make sure that -infinity
+ * was not asked for. Some implementations of strtod
+ * return inf when passed -inf
+ */
+ if(pg_strncasecmp(num,-Infinity,9)==0 ||
+pg_strncasecmp(num,-Inf,4)==0) {
+ val = -get_float4_infinity();
+ }
+ }
+ #endif
PG_RETURN_FLOAT4((float4) val);
}
***
*** 494,499
--- 522,542
}
#endif /* HAVE_BUGGY_SOLARIS_STRTOD */
+ #ifdef HAVE_BUGGY_IRIX_STRTOD
+ if(endptr != num pg_strncasecmp(endptr,inity,5)==0
+ endptr - num =4
+ (pg_strncasecmp(num,infinity,8)==0 ||
+ pg_strncasecmp(num,-infinity,9)==0 ) )
+ {
+ /**
+ *
+ * Some versions of strtod (IRIX) stop
+ * parsing after inf and leave endptr as inity
+ */
+ endptr+=5;
+ }
+ #endif
+
/* skip trailing whitespace */
while (*endptr != '\0' isspace((unsigned char) *endptr))
endptr++;
***
*** 507,513
if (!isinf(val))
CheckFloat8Val(val);
!
PG_RETURN_FLOAT8(val);
}
--- 550,568
if (!isinf(val))
CheckFloat8Val(val);
! #ifdef HAVE_BUGGY_IRIX_STRTOD
! else {
! /**
! * If val is infinity, make sure that -infinity
! * was not asked for. Some implementations of strtod
! * return inf when passed -inf
! */
! if(pg_strncasecmp(num,-Infinity,9)==0 ||
!pg_strncasecmp(num,-Inf,4)==0) {
! val = -get_float8_infinity();
! }
! }
! #endif
PG_RETURN_FLOAT8(val);
}
Index: include/port/irix.h
===
RCS file: /projects/cvsroot/pgsql/src/include/port/irix.h,v
retrieving revision 1.3
diff -c -r1.3 irix.h
*** include/port/irix.h 11 Mar 2006 04:38:38 - 1.3
--- include/port/irix.h 4 Oct 2006 21:16:23 -
***
*** 1
--- 1,2
/* $PostgreSQL: pgsql/src/include/port/irix.h,v 1.3 2006/03/11 04:38:38
momjian Exp $ */
+ #define HAVE_BUGGY_IRIX_STRTOD 1
Index: test/regress/expected/float4.out
===
RCS file: /projects/cvsroot/pgsql/src/test/regress/expected/float4.out,v
retrieving revision 1.13
diff -c -r1.13 float4.out
*** test/regress/expected/float4.out7 Apr 2005 01:51:40 - 1.13
--- test/regress/expected/float4.out4 Oct 2006 21:16:25
Re: [HACKERS] Updated version of FAQ_Solaris
Patch applied. Thanks. --- Zdenek Kotala wrote: I updated FAQ_Solaris. I added new information related to Solaris 10, rewrote optimalization hints and add information about dtrace. I talked with Peter about Current maintainer role, and he said that this information says anything and should be deleted. Please, let me know your comments Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Netflix Prize data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I signed up for the Netflix Prize. (www.netflixprize.com) and downloaded their data and have imported it into PostgreSQL. Here is how I created the table: I signed up as well, but have the table as follows: CREATE TABLE rating ( movie SMALLINT NOT NULL, person INTEGER NOT NULL, rating SMALLINT NOT NULL, viewed DATE NOT NULL ); I also recommend not loading the entire file until you get further along in the algorithm solution. :) Not that I have time to really play with this - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200610041827 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFFJDZ0vJuQZxSWSsgRAr6OAKCiOuspNm8QCsujaEN0Kgie6RsTjgCdGPda 9zVzpkrhTEhySEVBwMBTOdU= =zF7u -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] workaround for buggy strtod is not necessary
Zdenek Kotala wrote: Bruce Momjian wrote: Zdenek Kotala wrote: Solaris had broken strtod function when parse Inf and Nan. See solaris.h. This bug has been fixed for all current versions of Solaris ( 8, 9, 10). See http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-62-1searchclause=108993-62 http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-34-1searchclause=112874-34 Workaround is not necessary now, but I'm not sure if workaround removing is good idea. There are some possible variants: 1) keep workaround in the code for compatibility with unpatched system and adjust comment in solaris.h 2) remove workaround and mention required Solaris patch in the Solaris.FAQ document 3) add some test into configure script and use workaround only on unpatched system. (It should be nightmare for packagers) #1. What do you want to change about the existing comment? /* * Many versions of Solaris have broken strtod() --- see bug #4751182. * For the moment we just assume they all do; it's probably not worth * the trouble to add a configure test for this. */ /* Many versions of Solaris had broken strtod() -- see bug #4751182. Now, it is fixed in recent versions of Solaris (8 and above -- see patch 108993-62 and 112874-34). However, there should be many unpatched system. For the moment we just assume they all do; it's probably not worth the trouble to add a configure test for this. */ It is only update that it is fixed and why workaround is not removed. OK, great information, updated comment is: /* * Many versions of Solaris have broken strtod() --- see bug #4751182. * This has been fixed in current versions of Solaris: * * http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-62-1searchclause=108993-62 * http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-34-1searchclause=112874-34 * * However, many people might not have patched versions, so * still use our own fix for the buggy version. */ -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Netflix Prize data
I signed up for the Netflix Prize. (www.netflixprize.com) and downloaded their data and have imported it into PostgreSQL. Here is how I created the table: I signed up as well, but have the table as follows: CREATE TABLE rating ( movie SMALLINT NOT NULL, person INTEGER NOT NULL, rating SMALLINT NOT NULL, viewed DATE NOT NULL ); I also recommend not loading the entire file until you get further along in the algorithm solution. :) Not that I have time to really play with this As luck would have it, I wrote a recommendations system based on music ratings a few years ago. After reading the NYT article, it seems as though one or more of the guys behind Net Perceptions is either helping them or did their system, I'm not sure. I wrote my system because Net Perceptions was too slow and did a lousy job. I think the notion of communities in general is an interesting study in statistics, but every thing I've seen in the form of bad recommendations shows that while [N] people may share certain tastes, but that doesn't nessisarily mean that what one likes the others do. This is especially flawed with movie rentals because it is seldom a 1:1 ratio of movies to people. There are often multiple people in a household. Also, movies are almost always for multiple people. Anyway, good luck! (Not better than me, of course :-) ---(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] Netflix Prize data
Mark Woodward [EMAIL PROTECTED] writes: The one thing I notice is that it is REAL slow. How fast is your disk? Counting on my fingers, I estimate you are scanning the table at about 47MB/sec, which might or might not be disk-limited... I'm using 8.1.4. The rdate field looks something like: 2005-09-06 So why aren't you storing it as type date? You are assuming I gave it any thought at all. :-) I converted it to a date type (create table ratings2 as ) [EMAIL PROTECTED]:~/netflix/download$ time psql -c select count(*) from ratings netflix count --- 100480507 (1 row) real1m29.852s user0m0.002s sys 0m0.005s That's about the right increase based on the reduction in data size. OK, I guess I am crying wolf, 47M/sec isn't all that bad for the system. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Netflix Prize data
Greg Sabino Mullane [EMAIL PROTECTED] writes: CREATE TABLE rating ( movie SMALLINT NOT NULL, person INTEGER NOT NULL, rating SMALLINT NOT NULL, viewed DATE NOT NULL ); You would probably be better off putting the two smallints first followed by the integer and date. Otherwise both the integer and the date field will have an extra two bytes of padding wasting 4 bytes of space. If you reorder the fields that way you'll be down to 28 bytes of tuple header overhead and 12 bytes of data. There's actually another 4 bytes in the form of the line pointer so a total of 44 bytes per record. Ie, almost 73% of the disk i/o you're seeing is actually per-record overhead. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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] Updated version of FAQ_Solaris
Zdenek, Bruce, Has anyone updated the Solaris portion of runtime.sgml yet? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Netflix Prize data
Greg Sabino Mullane [EMAIL PROTECTED] writes: CREATE TABLE rating ( movie SMALLINT NOT NULL, person INTEGER NOT NULL, rating SMALLINT NOT NULL, viewed DATE NOT NULL ); You would probably be better off putting the two smallints first followed by the integer and date. Otherwise both the integer and the date field will have an extra two bytes of padding wasting 4 bytes of space. If you reorder the fields that way you'll be down to 28 bytes of tuple header overhead and 12 bytes of data. There's actually another 4 bytes in the form of the line pointer so a total of 44 bytes per record. Ie, almost 73% of the disk i/o you're seeing is actually per-record overhead. That's good advice, however, It is said that Netflix has greater than 64K movies, so, while the test info may work with a small int, I doubt the overall system would work. The rating, however, is one char 1~9. Would making it a char(1) buy anything? In wonder If I started screwing around with movie ID and rating, and moved them into one int. One byte for rating, three bytes for movie ID. That could reduce the data size by at least half gig. ---(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] Netflix Prize data
Mark Woodward [EMAIL PROTECTED] writes: The rating, however, is one char 1~9. Would making it a char(1) buy anything? No, that would actually hurt because of the length word for the char field. Even if you used the char type, which really is only one byte, you wouldn't win anything because of alignment issues. Personally I'd just go for three ints and a date, rather than trying to be cute with the rating. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Netflix Prize data
Mark Woodward [EMAIL PROTECTED] writes:
The rating, however, is one char 1~9. Would making it a char(1) buy
anything?
No, that would actually hurt because of the length word for the char
field. Even if you used the char type, which really is only one byte,
you wouldn't win anything because of alignment issues. Personally I'd
just go for three ints and a date, rather than trying to be cute with
the rating.
Actually, the date is just days, right? I don't actualy need it too much.
So, create a small int for date and do this: smalldate =
date('1970-01-01') - rdate. And use small int for rating.
Column | Type | Modifiers
+--+---
movie | integer |
client | integer |
day| smallint |
rating | smallint |
---(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] 8.2beta1 failure on IRIX
Steve Singer [EMAIL PROTECTED] writes: Some searching of the net shows that this has been reported before. Once in the beta for 8.1 and again in January as bug #2192 (It looks like a patch was included then but wasn't applied). Yeah, I see that, not sure why we didn't apply that patch. Will work on this. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2beta1 failure on IRIX
I've applied the attached patch which merges ideas from your version and
John Jorgensen's. Please check it.
regards, tom lane
*** src/backend/utils/adt/float.c.orig Tue Oct 3 23:16:36 2006
--- src/backend/utils/adt/float.c Wed Oct 4 21:21:17 2006
***
*** 328,333
--- 328,359
}
#endif /* HAVE_BUGGY_SOLARIS_STRTOD */
+ #ifdef HAVE_BUGGY_IRIX_STRTOD
+ /*
+* In some IRIX versions, strtod() recognizes only inf, so if the
+* input is infinity we have to skip over inity. Also, it may
+* return positive infinity for -inf.
+*/
+ if (isinf(val))
+ {
+ if (pg_strncasecmp(num, Infinity, 8) == 0)
+ {
+ val = get_float4_infinity();
+ endptr = num + 8;
+ }
+ else if (pg_strncasecmp(num, -Infinity, 9) == 0)
+ {
+ val = -get_float4_infinity();
+ endptr = num + 9;
+ }
+ else if (pg_strncasecmp(num, -inf, 4) == 0)
+ {
+ val = -get_float4_infinity();
+ endptr = num + 4;
+ }
+ }
+ #endif /* HAVE_BUGGY_IRIX_STRTOD */
+
/* skip trailing whitespace */
while (*endptr != '\0' isspace((unsigned char) *endptr))
endptr++;
***
*** 494,499
--- 520,551
endptr--;
}
#endif /* HAVE_BUGGY_SOLARIS_STRTOD */
+
+ #ifdef HAVE_BUGGY_IRIX_STRTOD
+ /*
+* In some IRIX versions, strtod() recognizes only inf, so if the
+* input is infinity we have to skip over inity. Also, it may
+* return positive infinity for -inf.
+*/
+ if (isinf(val))
+ {
+ if (pg_strncasecmp(num, Infinity, 8) == 0)
+ {
+ val = get_float8_infinity();
+ endptr = num + 8;
+ }
+ else if (pg_strncasecmp(num, -Infinity, 9) == 0)
+ {
+ val = -get_float8_infinity();
+ endptr = num + 9;
+ }
+ else if (pg_strncasecmp(num, -inf, 4) == 0)
+ {
+ val = -get_float8_infinity();
+ endptr = num + 4;
+ }
+ }
+ #endif /* HAVE_BUGGY_IRIX_STRTOD */
/* skip trailing whitespace */
while (*endptr != '\0' isspace((unsigned char) *endptr))
*** src/include/port/irix.h.origFri Mar 10 23:38:38 2006
--- src/include/port/irix.h Wed Oct 4 21:20:50 2006
***
*** 1
--- 1,7
/* $PostgreSQL: pgsql/src/include/port/irix.h,v 1.3 2006/03/11 04:38:38
momjian Exp $ */
+
+ /*
+ * IRIX 6.5.26f and 6.5.22f (at least) have a strtod() that accepts
+ * infinity, but leaves endptr pointing to inity.
+ */
+ #define HAVE_BUGGY_IRIX_STRTOD
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Updated version of FAQ_Solaris
Josh Berkus wrote: Zdenek, Bruce, Has anyone updated the Solaris portion of runtime.sgml yet? No, I was unaware it needed updating. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] minor change on comments on lock.h
To match the description on http://momjian.us/main/writings/pgsql/sgml/explicit-locking.html*** ../../include/storage/lock.h.orig 2006-10-05 00:25: 06.0 -0300--- ../../include/storage/lock.h 2006-10-05 00:31:16.0 -0300** 109,116 #define AccessShareLock 1 /* SELECT */ #define RowShareLock 2 /* SELECT FOR UPDATE/FOR SHARE */ #define RowExclusiveLock 3 /* INSERT, UPDATE, DELETE */! #define ShareUpdateExclusiveLock 4 /* VACUUM (non-FULL) */! #define ShareLock5 /* CREATE INDEX */ #define ShareRowExclusiveLock 6 /* like EXCLUSIVE MODE, but allows ROW * SHARE */ #define ExclusiveLock 7 /* blocks ROW SHARE/SELECT...FOR--- 109,117 #define AccessShareLock 1 /* SELECT */ #define RowShareLock 2 /* SELECT FOR UPDATE/FOR SHARE */ #define RowExclusiveLock 3 /* INSERT, UPDATE, DELETE */! #define ShareUpdateExclusiveLock 4 /* VACUUM (non-FULL),ANALYZE, CREATE ! * INDEX CONCURRENTLY */! #define ShareLock5 /* CREATE INDEX (WITHOUT CONCURRENTLY) */ #define ShareRowExclusiveLock 6 /* like EXCLUSIVE MODE, but allows ROW * SHARE */ #define ExclusiveLock 7 /* blocks ROW SHARE/SELECT...FOR[]'s- Walter
Re: [HACKERS] Digging gram.y
On Wed, Oct 04, 2006 at 09:04:11PM +0400, Teodor Sigaev wrote: Why do you want to? Just simplify. For instance I can see reasons for wanting SETOF on a function's input parameter (to pass it a whole table or select result in one call). I see. But Typename is used for table's definition for example. I can't imagine column setof text. It's part of the SQL:2003 standard as MULTISET :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
