
After over 3 months of intense development, the PostgreSQL Development
Group is proud to announce that the source code is no longer considered
ALPHA software.  With a development freeze effective today (February 1st),
we now enter BETA test mode, with a release date set for March 1st.

There has been alot of work done on the various aspects of the software,
including alot of new SQL related features.

One of the main priorities for the next month is to ensure that the ports
work, both as far as compiling and regression tests are concerned, which
is where we need *everyones* help.

For those wishing to aid in debugging for your various operating system,
you can grab the source code at:

		ftp.postgresql.org/pub/postgresql.snapshot.tar.gz

This gets regenerated every morning.

Once compiled and after having run the regression tests, there is now a
file created called 'regression.diffs', which is the diffs of all the
'failed' tests.  Please submit this file, via ftp, to

	ftp.postgresql.org/pub/incoming/regression.<OS>-<Version>

This will be used to help debug various 'idiosyncracies'.  Check the
src/test/regress directory for a regression.<operating system> file to
compare against before submitting...see if there are any differences.

Finally, we've also added in 'port specific' expected/*.out results, so
that we can take into consideration minor differences (but legit) between
the actually results an Operating System provides and that expected based
on our "base system" 

Included below is what has changed since v6.2.1 was released...


Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

=======================================
PostgreSQL 6.3               Sun Feb  1 14:57:30 EST 1998
-------------------------------------------------------------

A dump/restore is required for those wishing to migrate data from
previous releases of PostgreSQL.

CHANGES IN THE 6.3 RELEASE
--------------------------

Bug Fixes
---------
Fix binary cursors broken by MOVE implementation(Vadim)
Fix for tcl library crash(Jan)
Fix for array handling, from Gerhard Hintermayer
Fix acl error, and remove duplicate pqtrace(Bruce)
Fix psql \e for empty file(Bruce)
Fix for textcat on varchar() fields(Bruce)
Fix for DBT Sendproc (Zeugswetter Andres)
Fix vacuum analyze syntax problem(Bruce)
Fix for international identifiers(Tatsuo)
Fix aggregates on inherited tables(Bruce)
Fix substr() for out-of-bounds data
Fix for select 1=1 or 2=2, select 1=1 and 2=2, and select sum(2+2)(Bruce)
Fix notty output to show status result.  -q option still turns it off(Bruce)
Fix for count(*), aggs with views and multiple tables and sum(3)(Bruce)
Fix cluster(Bruce)
Fix for PQtrace start/stop several times(Bruce)
Fix a variety of locking problems like newer lock waiters getting
	lock before older waiters, and having readlock people not share
	locks if a writer is waiting for a lock, and waiting writers not
	getting priority over waiting readers(Bruce)
Fix crashes in psql when executing queries from external files(James)
Fix problem with multiple order by columns, with the first one having
	NULL values(Jeroen)
Use correct hash table support functions for float8 and int4(Thomas)
Re-enable JOIN= option in CREATE OPERATOR statement (Thomas)
Change precedence for boolean operators to match expected behavior(Thomas)
Generate elog(ERROR) on over-large integer(Bruce)
Allow multiple-argument functions in constraint clauses(Thomas)
Check boolean input literals for 'true','false','yes','no','1','0'
	and throw elog(ERROR) if unrecognized(Thomas)


Enhancements
------------
Real deadlock detection, no more timeouts(Bruce)
<NOT DONE YET> Subselects with EXISTS, IN, ALL, ANY keywords (Vadim, Bruce, Thomas)
Add SQL92 "constants" CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, 
	CURRENT_USER(Thomas)
Speedup by inlining some frequently-called functions
Modify constraint syntax to be SQL92-compliant(Thomas)
Implement SQL92 PRIMARY KEY and UNIQUE clauses using indices(Thomas)
Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas)
Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas)
Allow Postgres-style casting ("::") of non-constants(Thomas)
Add support for SQL3 TRUE and FALSE boolean constants(Thomas)
Support SQL92 syntax for IS TRUE/IS FALSE/IS NOT TRUE/IS NOT FALSE(Thomas)
Allow shorter strings for boolean literals (e.g. "t", "tr", "tru")(Thomas)
Allow SQL92 delimited identifiers(Thomas)
Implement SQL92 binary and hexadecimal string decoding (b'10' and x'1F')(Thomas)
Support SQL92 syntax for type coercion of literal strings
	(e.g. "DATETIME 'now'")(Thomas)
Add conversions for int2, int4, and OID types to and from text(Thomas)
Use shared lock when building indices(Vadim)
Free memory allocated for an user query inside transaction block after
	this query is done, was turned off in <= 6.2.1(Vadim)
New SQL statement CREATE PROCEDURAL LANGUAGE(Jan)
New PostgreSQL Procedural Language (PL) backend interface(Jan)
Rename pg_dump -H option to -h(Bruce)
Add Java support for passwords, European dates(Peter)
Use indices for LIKE and ~, !~ operations(Bruce)
Add hash functions for datetime and timespan(Thomas)
Time Travel removed(Vadim, Bruce)
Add paging for \d and \z, and fix \i(Bruce)
Add Unix domain socket support to backend and to frontend library(Goran)
Implement CREATE DATABASE/WITH LOCATION and initlocation utility(Thomas)
Allow more SQL92 and/or Postgres reserved words as column identifiers(Thomas)
Augment support for SQL92 SET TIME ZONE...(Thomas)
SET/SHOW/RESET TIME ZONE uses TZ backend environment variable(Thomas)
Implement SET keyword = DEFAULT and SET TIME ZONE DEFAULT(Thomas)
Enable SET TIME ZONE using TZ environment variable(Thomas)
Add PGDATESTYLE environment variable to frontend and backend initialization(Thomas)
Add PGTZ, PGCOSTHEAP, PGCOSTINDEX, PGRPLANS, PGGEQO
	frontend library initialization environment variables(Thomas)
Regression tests time zone automatically set with "setenv PGTZ PST8PDT"(Thomas)
Add pg_description table for info on tables, columns, operators, types, and
	aggregates(Bruce)
Increase 16 char limit on system table/index names to 32 characters(Bruce)
Rename system indices(Bruce)
Add 'GERMAN' option to SET DATESTYLE(Thomas)
Define an "ISO-style" timespan output format with "hh:mm:ss" fields(Thomas)
Allow fractional values for delta times (e.g. '2.5 days')(Thomas)
Validate numeric input more carefully for delta times(Thomas)
Implement day of year as possible input to date_part()(Thomas)
Define timespan_finite() and text_timespan() functions(Thomas)
Remove archive stuff(Bruce)
Allow for a pg_password authentication database that is separate from
	the system password file(Todd)
Dump ACLs, GRANT, REVOKE permissions(Matt)
Define text, varchar, and bpchar string length functions(Thomas)
Fix Query handling for inheritance, and cost computations(Bruce)
Implement CREATE TABLE/AS SELECT (alternative to SELECT/INTO)(Thomas)
Allow NOT, IS NULL, IS NOT NULL in constraints(Thomas)
Implement UNIONs for SELECT(Bruce)
Add UNION, GROUP, DISTINCT to INSERT(Bruce)
varchar() stores only necessary bytes on disk(Bruce)
Fix for BLOBs(Peter)
Mega-Patch for JDBC...see README_6.3 for list of changes(Peter)
Allow installation data block size and max tuple size configuration(Darren)
Remove unused "option" from PQconnectdb()
New LOCK command and lock manual page describing deadlocks(Bruce)
Add new psql \da, \dd, \df, \do, \dS, and \dT commands(Bruce)
Enhance psql \z to show sequences(Bruce)
Show NOT NULL and DEFAULT in psql \d table(Bruce)
New psql .psqlrc file startup(Andrew)
Modify sample startup script in contrib/linux to show syslog(Thomas)
New types for IP and MAC addresses in contrib/ip_and_mac(TomH)
Unix system time conversions with date/time types in contrib/unixdate(Thomas)
Update of contrib stuff(Massimo)
Add Unix socket support to DBD::Pg(Goran)
New python interface (PyGreSQL 2.0)(D'Arcy)
New frontend/backend protocol has a version number, network byte order(Phil)
Security features in pg_hba.conf enhanced and documented, many cleanups(Phil)
New HTML and Postscript documentation(Thomas)


Source Tree Changes
-------------------
Add new html development tools, and flow chart in /tools/backend
Fix for SCO compiles
Stratus computer port "Gillies, Robert" <GilliesR@Nichols.com>
Added support for shlib for BSD44_derived & i386_solaris
Make configure more automated(Brook)
Add script to check regression test results
Break parser functions into smaller files, group together(Bruce)
Rename heap_create to heap_create_and_catalog, rename heap_creatr
	to heap_create()(Bruce)
Sparc/Linux patch for locking(TomS)
Remove PORTNAME and reorganize port-specific stuff(Marc)
Add optimizer README file(Bruce)
Remove some recursion in optimizer and clean up some code there(Bruce)
Fix for NetBSD locking(Henry)
Fix for libptcl make(Tatsuo)
AIX patch(Darren)
Change IS TRUE, IS FALSE, ... to expressions using "=" rather than
	function calls to istrue() or isfalse() to allow optimization(Thomas)
Various fixes NetBSD/Sparc related(TomH)
Alpha linux locking(Travis,Ryan)
Change elog(WARN) to elog(ERROR)(Bruce)
FAQ for FreeBSD(Marc)
Bring in the PostODBC source tree as part of our standard distribution(Marc)
A minor patch for HP/UX 10 vs 9(Stan)
New pg_attribute.atttypmod for type-specific info like varchar length(Bruce)
Unixware patches(Billy)
New i386 'lock' for spin lock asm(Billy)
Support for multiplexed backends is removed
Start an OpenBSD port
Start an AUX port
Start a Cygnus port
Add string functions to regression suite(Thomas)
Expand a few function names formerly truncated to 16 characters(Thomas)




Sun, 1 Feb 1998 20:47:18 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
v6.3beta testing starting
Hi,

compiling on sparc-solaris 2.5 with gcc.

tas not defined error.

gmake[3]: Entering directory `/amd/dolphin/export/database22/data-mining/postgr
e
s/pgsql/src/backend/storage/buffer'
gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
s
  -Wall -Wmissing-prototypes -I../..    -c buf_table.c -o buf_table.o
gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
s
  -Wall -Wmissing-prototypes -I../..    -c buf_init.c -o buf_init.o
../../../include/storage/s_lock.h:123: warning: `tas' declared `static' but 
neve
r defined
gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
s
  -Wall -Wmissing-prototypes -I../..    -c bufmgr.c -o bufmgr.o
../../../include/storage/s_lock.h:123: warning: `tas' declared `static' but 
neve
r defined
gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
s
  -Wall -Wmissing-prototypes -I../..    -c freelist.c -o freelist.o
gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
s
  -Wall -Wmissing-prototypes -I../..    -c localbuf.c -o localbuf.o
gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
s
  -Wall -Wmissing-prototypes -I../..    -c s_lock.c -o s_lock.o
../../../include/storage/s_lock.h:123: warning: `tas' declared `static' but 
neve
r defined

later the linking fails:
gcc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o 
commands/SUB
SYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o 
nodes/SUBSYS.o
 optimizer/SUBSYS.o parser/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o 
regex/SUBS
YS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o 
../utils/ver
sion.o -lgen -lcrypt -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lcurses
Undefined           first referenced
 symbol                 in file
tas                                 storage/SUBSYS.o

--shiby



Mon, 02 Feb 1998 11:52:35 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
Compilation error on sparc-solaris
Hi,

It looks like the compilation problem on sparc_solaris is due to some
inconsistencies in the Makefiles. The -D$(PORTNAME) is not passed in 
CFLAGS. I made the foll. changes and it compiled fine.

I am attaching the diffs that I made to the Makefiles. Please let me know
if they are correct and if so fix them in the main source tree.
src/Makefile.global.in :
47,53d46
< # Note that portname is defined here to be UNDEFINED to remind you
< # to change it in Makefile.custom.
< #
< # make sure that you have no whitespaces after the PORTNAME setting
< # or the makefiles can get confused
< PORTNAME= @PORTNAME@
< 
285,287d279
< 
< # Globally pass PORTNAME
< CFLAGS+= -D$(PORTNAME)

src/backend/Makefile:
71c71
<       $(MAKE) -C $(subst .dir,,$@) all PORTNAME=$(PORTNAME)
---
>       $(MAKE) -C $(subst .dir,,$@) all 
107c107
<       for i in $(DIRS); do $(MAKE) -C $$i clean PORTNAME=$(PORTNAME); done
---
>       for i in $(DIRS); do $(MAKE) -C $$i clean; done
110c110
<       for i in $(DIRS); do $(MAKE) -C $$i $@ PORTNAME=$(PORTNAME); done
---
>       for i in $(DIRS); do $(MAKE) -C $$i $@; done
171c171
<       ./makeID $(PORTNAME)
---
>       ./makeID 

src/backend/port/Makefile: (Here I think the fix should be in Makefile.in; I 
just edited the Makefile to try if it fixes problem)
28c28
< OBJS = $(PORTNAME)/SUBSYS.o dynloader.o inet_aton.o   
---
> OBJS = dynloader.o inet_aton.o   
31c31
< all: submake SUBSYS.o
---
> all: SUBSYS.o
37,39d36
< 
< submake:
<       $(MAKE) -C $(PORTNAME) SUBSYS.o

--shiby




Mon, 02 Feb 1998 14:06:13 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
compilation on sparc_solaris
On Mon, 2 Feb 1998, Shiby Thomas wrote:

> Hi,
> 
> It looks like the compilation problem on sparc_solaris is due to some
> inconsistencies in the Makefiles. The -D$(PORTNAME) is not passed in 
> CFLAGS. I made the foll. changes and it compiled fine.

	I hate to ask, but what version is the port for?  We already
removed all the PORTNAME stuff for v6.3 ;(



> I am attaching the diffs that I made to the Makefiles. Please let me know
> if they are correct and if so fix them in the main source tree.
> src/Makefile.global.in :
> 47,53d46
> < # Note that portname is defined here to be UNDEFINED to remind you
> < # to change it in Makefile.custom.
> < #
> < # make sure that you have no whitespaces after the PORTNAME setting
> < # or the makefiles can get confused
> < PORTNAME= @PORTNAME@
> < 
> 285,287d279
> < 
> < # Globally pass PORTNAME
> < CFLAGS+= -D$(PORTNAME)
> 
> src/backend/Makefile:
> 71c71
> <       $(MAKE) -C $(subst .dir,,$@) all PORTNAME=$(PORTNAME)
> ---
> >       $(MAKE) -C $(subst .dir,,$@) all 
> 107c107
> <       for i in $(DIRS); do $(MAKE) -C $$i clean PORTNAME=$(PORTNAME); done
> ---
> >       for i in $(DIRS); do $(MAKE) -C $$i clean; done
> 110c110
> <       for i in $(DIRS); do $(MAKE) -C $$i $@ PORTNAME=$(PORTNAME); done
> ---
> >       for i in $(DIRS); do $(MAKE) -C $$i $@; done
> 171c171
> <       ./makeID $(PORTNAME)
> ---
> >       ./makeID 
> 
> src/backend/port/Makefile: (Here I think the fix should be in Makefile.in; I 
> just edited the Makefile to try if it fixes problem)
> 28c28
> < OBJS = $(PORTNAME)/SUBSYS.o dynloader.o inet_aton.o   
> ---
> > OBJS = dynloader.o inet_aton.o   
> 31c31
> < all: submake SUBSYS.o
> ---
> > all: SUBSYS.o
> 37,39d36
> < 
> < submake:
> <       $(MAKE) -C $(PORTNAME) SUBSYS.o
> 
> --shiby
> 
> 

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 2 Feb 1998 20:46:20 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: compilation on sparc_solaris
=> On Mon, 2 Feb 1998, Shiby Thomas wrote:
=> 
=> > Hi,
=> > 
=> > It looks like the compilation problem on sparc_solaris is due to some
=> > inconsistencies in the Makefiles. The -D$(PORTNAME) is not passed in 
=> > CFLAGS. I made the foll. changes and it compiled fine.
=> 
=> 	I hate to ask, but what version is the port for?  We already
=> removed all the PORTNAME stuff for v6.3 ;(
=> 
Its the latest snapshot on Feb 2. Without the PORTNAME, flag, it didn't compile
when I tried. 
gcc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o 
commands/SUB
SYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o 
nodes/SUBSYS.o
 optimizer/SUBSYS.o parser/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o 
regex/SUBS
YS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o 
../utils/ver
sion.o -lgen -lcrypt -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lcurses
Undefined           first referenced
 symbol                 in file
tas                                 storage/SUBSYS.o
ld: fatal: Symbol referencing errors. No output written to postgres

It also gave the foll. warning while compiling in the backend/storage dir
gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
s
  -Wall -Wmissing-prototypes -Dsparc_solaris -I../..    -c spin.c -o spin.o
../../../include/storage/s_lock.h:123: warning: `tas' declared `static' but 
neve
r defined

--shiby



Mon, 02 Feb 1998 20:40:26 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
Re: compilation on sparc_solaris 

Fixed..should be okay for tomorrow mornings snapshot



On Mon, 2 Feb 1998, Shiby Thomas wrote:

> => On Mon, 2 Feb 1998, Shiby Thomas wrote:
> => 
> => > Hi,
> => > 
> => > It looks like the compilation problem on sparc_solaris is due to some
> => > inconsistencies in the Makefiles. The -D$(PORTNAME) is not passed in 
> => > CFLAGS. I made the foll. changes and it compiled fine.
> => 
> => 	I hate to ask, but what version is the port for?  We already
> => removed all the PORTNAME stuff for v6.3 ;(
> => 
> Its the latest snapshot on Feb 2. Without the PORTNAME, flag, it didn't compile
> when I tried. 
> gcc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o 
> commands/SUB
> SYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o 
> nodes/SUBSYS.o
>  optimizer/SUBSYS.o parser/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o 
> regex/SUBS
> YS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o 
> ../utils/ver
> sion.o -lgen -lcrypt -lnsl -lsocket -ldl -lm -lreadline -ltermcap -lcurses
> Undefined           first referenced
>  symbol                 in file
> tas                                 storage/SUBSYS.o
> ld: fatal: Symbol referencing errors. No output written to postgres
> 
> It also gave the foll. warning while compiling in the backend/storage dir
> gcc -I../../../include -I../../../backend  -I../../../backend/port/sparc_solari
> s
>   -Wall -Wmissing-prototypes -Dsparc_solaris -I../..    -c spin.c -o spin.o
> ../../../include/storage/s_lock.h:123: warning: `tas' declared `static' but 
> neve
> r defined
> 
> --shiby
> 

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 2 Feb 1998 22:06:30 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: compilation on sparc_solaris 
Hi,

The foll. query did not finish even after running for 20 HOURS. 
I remember some discussion about a self-join bug. Could it be because of that ?
This is with the snapshot on Feb 2. Foll. is the output of explain:
Here data is a table with 2 attributes(tid, item) and about 1.1 million tuples.
c2(item1, item2) has about 87,000 tuples. I am running on a 8 processor
sun sparc with a total of 2GB memory and each processor is a
248 MHz SUNW,UltraSPARC-II.
I invoked postmaster as:
 postmaster -B 30000 -o "-s -F -S 16384"
The tables does not have any indices right now. Will it help with indices
for the hash join plan ?

assoc=> explain select item1, item2, count(t1.tid) into table f2_temp from 
data t1, data t2, c2 where t1.item = c2.item1 and t2.item = c2.item2 and 
t1.tid = t2.tid group by item1, item2;
NOTICE:  QUERY PLAN:

Aggregate  (cost=211518.56 size=0 width=0)
  ->   Group  (cost=211518.56 size=0 width=0)
    ->     Sort  (cost=211518.56 size=0 width=0)
      ->       Hash Join  (cost=211518.56 size=14 width=24)
        ->         Hash Join  (cost=89881.04 size=1154369 width=16)
          ->           Seq Scan on t2  (cost=45447.18 size=1154369 width=8)
          ->           Hash  (cost=0.00 size=0 width=0)
            ->             Seq Scan on c2  (cost=3447.84 size=87571 width=8)
        ->         Hash  (cost=0.00 size=0 width=0)
          ->           Seq Scan on t1  (cost=45447.18 size=1154369 width=8)

EXPLAIN



Tue, 03 Feb 1998 10:58:32 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
Execution time.
Shiby Thomas wrote:
> 
> Hi,
> 
> The foll. query did not finish even after running for 20 HOURS.
> I remember some discussion about a self-join bug. Could it be because of that ?

No. Self-join is problem of old optimizer, not executor. You got output
from EXPLAIN ==> optimizer' phase is done.

> This is with the snapshot on Feb 2. Foll. is the output of explain:
> Here data is a table with 2 attributes(tid, item) and about 1.1 million tuples.
> c2(item1, item2) has about 87,000 tuples. I am running on a 8 processor
> sun sparc with a total of 2GB memory and each processor is a
> 248 MHz SUNW,UltraSPARC-II.
> I invoked postmaster as:
>  postmaster -B 30000 -o "-s -F -S 16384"
                 ^^^^^
240M of shared memory ?!

> The tables does not have any indices right now. Will it help with indices
> for the hash join plan ?
          ^^^^^^^^^^^^^^
No. But indices could be used in nestloop plan...

> 
> assoc=> explain select item1, item2, count(t1.tid) into table f2_temp from
> data t1, data t2, c2 where t1.item = c2.item1 and t2.item = c2.item2 and
> t1.tid = t2.tid group by item1, item2;
> NOTICE:  QUERY PLAN:
> 
> Aggregate  (cost=211518.56 size=0 width=0)
>   ->   Group  (cost=211518.56 size=0 width=0)
>     ->     Sort  (cost=211518.56 size=0 width=0)
>       ->       Hash Join  (cost=211518.56 size=14 width=24)
>         ->         Hash Join  (cost=89881.04 size=1154369 width=16)
>           ->           Seq Scan on t2  (cost=45447.18 size=1154369 width=8)
>           ->           Hash  (cost=0.00 size=0 width=0)
>             ->             Seq Scan on c2  (cost=3447.84 size=87571 width=8)
>         ->         Hash  (cost=0.00 size=0 width=0)
>           ->           Seq Scan on t1  (cost=45447.18 size=1154369 width=8)
                                                             ^^^^^^^
Your big table data will be entirely in memory (this is caused
by -B 30000).

Ok. First, try to create indices on both tables.
Does it help ?
EXPLAIN ?

Vadim

Wed, 04 Feb 1998 10:09:59 +0700
"Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Re: [HACKERS] Execution time.

=> > I invoked postmaster as:
=> >  postmaster -B 30000 -o "-s -F -S 16384"
=>                  ^^^^^
=> 240M of shared memory ?!
=> 
Is the size of the hash bucket dependent on the number of buffers available ?
If so, with -B 30000, it might create huge hash buckets and hence the
hash join could degenerate to a nested loops join. Is that possible -- just
checking. What could be good values for -B and -S. The largest table I am
joining is about 60M

Thanks
--shiby




Wed, 04 Feb 1998 11:26:11 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
Re: [HACKERS] Execution time. 
On Wed, 4 Feb 1998, Shiby Thomas wrote:

> 
> => > I invoked postmaster as:
> => >  postmaster -B 30000 -o "-s -F -S 16384"
> =>                  ^^^^^
> => 240M of shared memory ?!
> => 
> Is the size of the hash bucket dependent on the number of buffers available ?
> If so, with -B 30000, it might create huge hash buckets and hence the
> hash join could degenerate to a nested loops join. Is that possible -- just
> checking. What could be good values for -B and -S. The largest table I am
> joining is about 60M

	My production server runs with a -B 256, and a -S 10240



Wed, 4 Feb 1998 11:38:04 -0500 (EST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Execution time. 
Hi,

assoc=> explain insert into f2_temp select p.item, q.item, count(*) as cnt 
from t1 p, t1 q where p.tid = q.tid and p.item < q.item group by p.item, 
q.item;
ERROR:  The field being grouped by must appear in the target list

However, it works this way:
assoc=> explain select p.item, q.item, count(*) as cnt into table f2_temp from 
t1 p, t1 q where p.tid = q.tid and p.item < q.item group by p.item, q.item;
NOTICE:  QUERY PLAN:

--shiby



Wed, 04 Feb 1998 12:56:53 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
Is this a parser error ?

=> > Is the size of the hash bucket dependent on the number of buffers available ?
=> > If so, with -B 30000, it might create huge hash buckets and hence the
=> > hash join could degenerate to a nested loops join. Is that possible -- just
=> > checking. What could be good values for -B and -S. The largest table I am
=> > joining is about 60M
=> 
=> 	My production server runs with a -B 256, and a -S 10240
=> 
=> 
With less buffers, it is giving "hash table out of memory" error.
I ran with -B 512

AGG :c=435416.5312 :s=0 :w=0 
   l: GROUP :c=435416.5312 :s=0 :w=0 
      l: SORT :c=435416.5312 :s=0 :w=0 
         l: HASHJOIN :c=435416.5312 :s=305715 :w=16 
            l: SEQSCAN :c=36107.7500 :s=917144 :w=8  ( t1 )
            r: HASH :c=0.0000 :s=0 :w=0 
               l: SEQSCAN :c=36107.7500 :s=917144 :w=8  ( t1 )
ERROR:  hash table out of memory. Use -B parameter to increase buffers.



Wed, 04 Feb 1998 13:07:01 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
Re: [HACKERS] Execution time. 
Hi,

I get the foll.  error in a select statement:

assoc=> select * from f1_temp where cnt > 1000;
ERROR:  fmgr_info: function 0: cache lookup failed

Without the where clause its fine.

This is with today's (Feb 4) snapshot.

--shiby




Wed, 04 Feb 1998 14:15:10 -0500
Shiby Thomas <sthomas@cise.ufl.edu>
Error in select
> 
> Hi,
> 
> I get the foll.  error in a select statement:
> 
> assoc=> select * from f1_temp where cnt > 1000;
> ERROR:  fmgr_info: function 0: cache lookup failed
> 
> Without the where clause its fine.
> 
> This is with today's (Feb 4) snapshot.
> 

Yep, we know the cause, and will fix it soon.  Sorry.
-- 
Bruce Momjian
maillist@candle.pha.pa.us

Wed, 4 Feb 1998 14:35:03 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Error in select
Shiby Thomas wrote:
> 
> => > Is the size of the hash bucket dependent on the number of buffers available ?
> => > If so, with -B 30000, it might create huge hash buckets and hence the
> => > hash join could degenerate to a nested loops join. Is that possible -- just
> => > checking. What could be good values for -B and -S. The largest table I am
> => > joining is about 60M
> =>
> =>      My production server runs with a -B 256, and a -S 10240
> =>
> =>
> With less buffers, it is giving "hash table out of memory" error.

Known bug...

> I ran with -B 512
> 
> AGG :c=435416.5312 :s=0 :w=0
>    l: GROUP :c=435416.5312 :s=0 :w=0
>       l: SORT :c=435416.5312 :s=0 :w=0
>          l: HASHJOIN :c=435416.5312 :s=305715 :w=16
>             l: SEQSCAN :c=36107.7500 :s=917144 :w=8  ( t1 )
>             r: HASH :c=0.0000 :s=0 :w=0
>                l: SEQSCAN :c=36107.7500 :s=917144 :w=8  ( t1 )
> ERROR:  hash table out of memory. Use -B parameter to increase buffers.

Try to create indices...

Vadim

Thu, 05 Feb 1998 08:51:25 +0700
"Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Re: [HACKERS] Execution time.
> > I get the foll.  error in a select statement:
> >
> > assoc=> select * from f1_temp where cnt > 1000;
> > ERROR:  fmgr_info: function 0: cache lookup failed
> >
> > Without the where clause its fine.
> >
> > This is with today's (Feb 4) snapshot.
> >
>
> Yep, we know the cause, and will fix it soon.  Sorry.

Try doing a "make clean; make install" since possibly the problem is due
to my changing a few keywords (got rid of two!) in the parser. It seems
this quite often requires a clean install since I don't know which
places are affected and it affects more than just the parser directory.

Don't need to reload the database though.

                                          - Tom


Thu, 05 Feb 1998 02:25:02 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Error in select