[COMMITTERS] pgsql-server/src/backend/executor nodeIndexscan.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/30 16:05:05 Modified files: src/backend/executor: nodeIndexscan.c Log message: Avoid running out of memory during hash_create, by not passing a number-of-buckets that exceeds the size we actually plan to allow the hash table to grow to. Per trouble report from Sean Shanny. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[COMMITTERS] pgsql-server/src/backend/executor Tag: REL7_4_ ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/30 16:05:15 Modified files: src/backend/executor: Tag: REL7_4_STABLE nodeIndexscan.c Log message: Avoid running out of memory during hash_create, by not passing a number-of-buckets that exceeds the size we actually plan to allow the hash table to grow to. Per trouble report from Sean Shanny. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[COMMITTERS] pgsql-server/src/backend/optimizer README prep ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/30 17:49:19 Modified files: src/backend/optimizer: README src/backend/optimizer/prep: prepqual.c Log message: Instead of trying to force WHERE clauses into CNF or DNF normal form, just look for common clauses that can be pulled out of ORs. Per recent discussion, extracting common clauses seems to be the only really useful effect of normalization, and if we do it explicitly then we can avoid cluttering the qual with partially-redundant duplicated expressions, which was an unpleasant side-effect of the old approach. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[COMMITTERS] pgsql-server/src/template solaris
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/30 19:13:51 Modified files: src/template : solaris Log message: Add "-mt" link flag for Solaris non-gcc compiles when using threads --- required. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[COMMITTERS] pgsql-server/doc/src/sgml charset.sgml
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/30 19:36:19 Modified files: doc/src/sgml : charset.sgml Log message: Recommend SHOW, instead of pg_controldata, for checking LC_COLLATE and LC_CTYPE settings of a database. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[COMMITTERS] pgsql-server/src backend/nodes/copyfuncs.c bac ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/30 19:53:15 Modified files: src/backend/nodes: copyfuncs.c equalfuncs.c outfuncs.c src/backend/optimizer/path: indxpath.c joinpath.c src/backend/optimizer/plan: initsplan.c src/backend/optimizer/util: clauses.c restrictinfo.c src/include/nodes: relation.h src/include/optimizer: clauses.h Log message: Adjust the definition of RestrictInfo's left_relids and right_relids fields: now they are valid whenever the clause is a binary opclause, not only when it is a potential join clause (there is a new boolean field canjoin to signal the latter condition). This lets us avoid recomputing the relid sets over and over while examining indexes. Still more work to do to make this as useful as it could be, because there are places that could use the info but don't have access to the RestrictInfo node. ---(end of broadcast)--- TIP 3: 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
