> -----Original Message-----
> From: Lauri Pietarinen [mailto:lauri.pietarinen@atbusiness.com] 
> Sent: Sunday, October 19, 2003 1:50 PM
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Dreaming About Redesigning SQL
> 
> 
> Anthony W. Youngman wrote:
> 
> >Well, as far as we MV'ers are concerned, performance IS a 
> problem with 
> >the relational approach. The attitude (as far as I can tell) with 
> >relational is to hide the actual DB implementation from the 
> >programmers. So it is a design "flaw" that it is extremely 
> easy for a 
> >programmer to do something stupid. And you need a DBA to try and 
> >protect the database from the programmers!
> >
> >As soon as a requirement for a database specifies extraction of the 
> >maximum power from the box, it OUGHT to rule out all the current 
> >relational databases. MV flattens it for it for performance. 
> As an MV 
> >programmer, I *KNOW* that I can find any thing I'm looking 
> for (or find 
> >out it doesn't exist) with just ONE disk seek. A relational 
> programmer 
> >has to ask the db "does this exist" and hope the db is 
> optimised to be 
> >able to return the result quickly. To quote the Pick FAQ 
> "SQL optimises 
> >the easy task of finding stuff in memory. Pick optimises the 
> hard task 
> >of getting it into memory in the first place".
> >
> So in your opinion, is the problem
> 
> 1)  SQL is so hard that the average programmer will not know 
> how to use it efficiently or

This same average programmer will have the same difficulty with a pure,
orthogonal and mathematically rigorous language.

> 2)  Relational (or SQL-) DBMS'es are just too slow
> 
> If 2)  then why don't we get a bit more concrete.  Could you 
> give an example of a query that in your experience would be 
> too slow using a standard SQL database (e.g. Oracle, or 
> MySQL). We could then actually try it out on some machine and 
> compare.  I suggest using the 
> customer-order-order_detail-product database
> 
> If 1)  I would like to hear some concrete examples. 

I once worked on a telephone customer support system that had 5 million
lines of C++ and 5 million lines of SQL.  It was too complex for the
average person to comprehend.

There are always going to be some queries that are too slow.  If you put
a key on everything, data modifications will go into the toilet.  If you
lack a key on a field required for a filtered query, you will have a
table scan.  Hence, there is no free lunch, and there will have to be
compromises.  However, due to the exponential expansion of compute
power, the efficiency of SQL is the least of our worries.  See this
link, it makes for excellent reading:
http://www.kurzweilai.net/articles/art0134.html?printable=1 

> best regards,
> Lauri Pietarinen
> 
> 
> 
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index 
> scan if your
>       joining column's datatypes do not match
> 

Tue, 21 Oct 2003 11:38:15 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Dreaming About Redesigning SQL
Cygwin, 7.3.4
This thing is really KILLING us and our customers.

In pgerr.log this always go together:

WARNING:  ShmemAlloc: out of memory
ERROR:  FreeSpaceMap hashtable out of memory

Theses errors usually take place on INSERT statements like this one:

INSERT INTO params (param_id,map_id,param_key,param_value) VALUES
(0,858,'MAP_NAME','New Map')

params is just a simple table (no triggers or rules involved):
CREATE TABLE map_11.params
(
  param_id int4 NOT NULL,
  map_id int4 NOT NULL,
  param_key varchar(1024),
  param_value text,
  CONSTRAINT params_pkey PRIMARY KEY (param_id)
) WITH OIDS;


The db server machine has 4GB of physical memory and more than half is
always available.
Number of connection is 64
Number of buffers was increased to 81920 (but this does not help)


Is there any parameters that can be configured to increase available shared
memory size?


Any help is greatly appreciated.
Tue, 21 Oct 2003 12:56:12 -0700
"Yurgis Baykshtis" <ybaykshtis@micropat.com>
Help!!! FreeSpaceMap hashtalble out of memory.
"Yurgis Baykshtis" <ybaykshtis@micropat.com> writes:
> In pgerr.log this always go together:
> WARNING:  ShmemAlloc: out of memory
> ERROR:  FreeSpaceMap hashtable out of memory

If you have a large number of tables in your database, it might be that
you need to increase max_locks_per_transaction.

			regards, tom lane

Mon, 27 Oct 2003 11:51:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Help!!! FreeSpaceMap hashtalble out of memory. 