Обсуждение: v6.3beta testing starting
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)
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
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
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
=> 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
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
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
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
=> > 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
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
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
=> > 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.
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
> > 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
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
> > 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