Re: [GENERAL] Information about storge engine in PostgreSQL

2004-10-22 Thread nd02tsk
I really appreciate these type of high-quality anwsers, thank you.

Tim

 On 10/21/2004 10:27 AM, [EMAIL PROTECTED] wrote:

 Hello

 MySQL has information about several storage engines. MEMORY to handle
 temporary tables, InnoDB to handle transactions and which also can split
 its table data over several files/partitions. Splitting of storage is
 something which according to the following article, PostgreSQL does not
 support:

 For a long time the MySQL documentation was stating that foreign keys
 are mainly for documentation purposes and explained why you really
 didn't want them and why it was so much better that MySQL swallowed
 their syntax silently without any effect. Similarly dangerous opinions
 where documented about transactions and ACID features.

 Then the InnoDB table handler was added to MySQL and with the new
 features, namely transactions and referential integrity, the documented
 opinion about these features was changed. But since every other database
 had these features for long already, all that was left was now the
 capability of having different storage engines, and it became the new
 advantage feature to point out.

 Right now on their boiler plate is another buzzword compliant table
 handler, the NDB cluster storage engine. And while a lot of people are
 getting all excited about it, all I really see so far is yet another
 table handler that does not provide foreign keys, that does not
 integrate with the existing transaction systems ACID properties, and
 that has outrageous network and memory requirements. Especially worried
 am I about the fact that the responsibility for referential integrity,
 that was lifted from the developers shoulders with the InnoDB tables, is
 now dropped twice as heavy back into his laps. I don't think that Web
 developers who had problems getting integrity constraints implemented in
 the application before InnoDB will do this much better in a concurrent
 multimaster cluster environment. But I am sure enough PHB's who, free
 from every knowledge obstacles, fully believe in marketing speech will
 force their developers into that nightmare.

 None of all these advanced storage engines was developed by MySQL. They
 all got purchased and turned into table handlers. The multiple storage
 engine capability of MySQL is the technical base for stapling together
 those features, MySQL isn't able to build into the existing system and
 has to buy somewhere else.

 The PostgreSQL philosophy is a little different. That is why we have
 only one, tightly integrated and not very easy to replace storage engine.


 Jan

 --
 #==#
 # It's easier to get forgiveness for being wrong than for being right. #
 # Let's break this rule - forgive me.  #
 #== [EMAIL PROTECTED] #




---(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


[GENERAL] Information about storge engine in PostgreSQL

2004-10-21 Thread nd02tsk
Hello

MySQL has information about several storage engines. MEMORY to handle
temporary tables, InnoDB to handle transactions and which also can split
its table data over several files/partitions. Splitting of storage is
something which according to the following article, PostgreSQL does not
support:

http://www.devx.com/dbzone/Article/20743

But I cannot verify this due to lack of information. I haven't found any
similar information about the storage engine used by PostgreSQL which I
think is called Postgres.

Do you know of any places where this information can be obtained?


Thank you.


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [GENERAL] Information about storge engine in PostgreSQL

2004-10-21 Thread Andrew Sullivan
On Thu, Oct 21, 2004 at 04:27:24PM +0200, [EMAIL PROTECTED] wrote:
 Hello
 
 MySQL has information about several storage engines. 

I think you will find fairly broad agreement around here that the
idea of different storage engines for different jobs is a bad one. 
But to answer your question. . .

 its table data over several files/partitions. Splitting of storage is
 something which according to the following article, PostgreSQL does not
 support:
 
 http://www.devx.com/dbzone/Article/20743

In 8.0 (now in beta) that is false.  The feature you're looking for
is called tablespaces.

What PostgreSQL does _not_ have at the moment is the distributed
(multi-master) storage that MySQL is offering.  When PostgreSQL
delivers that (it's on my department's TODO list this year, FWIW: Jan
Wieck is working on it), we'll do so without the sorts of (IMHO
dangerous) failure modes that are present in the MySQL offering.  

 similar information about the storage engine used by PostgreSQL which I
 think is called Postgres.

There isn't really a separable storage engine in PostgreSQL. 
Depending on whom you ask, Postgres is either a short form of
PostgreSQL, an ancestor of PostgreSQL, or both.

 Do you know of any places where this information can be obtained?

Here :)

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what 
you told them to.  That actually seems sort of quaint now.
--J.D. Baldwin

---(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


Re: [GENERAL] Information about storge engine in PostgreSQL

2004-10-21 Thread Kevin Barnard
PostgreSQL uses it's own internal storage engine.  It doesn not
support multiple one.  As for splitting files accross partitions this
is a feature of version 8.0 called tablespaces.

http://developer.postgresql.org/docs/postgres/manage-ag-tablespaces.html

Should get you pointed in the right direction.


On Thu, 21 Oct 2004 16:27:24 +0200 (CEST), [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 Hello
 
 MySQL has information about several storage engines. MEMORY to handle
 temporary tables, InnoDB to handle transactions and which also can split
 its table data over several files/partitions. Splitting of storage is
 something which according to the following article, PostgreSQL does not
 support:
 
 http://www.devx.com/dbzone/Article/20743
 
 But I cannot verify this due to lack of information. I haven't found any
 similar information about the storage engine used by PostgreSQL which I
 think is called Postgres.
 
 Do you know of any places where this information can be obtained?
 
 Thank you.
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [GENERAL] Information about storge engine in PostgreSQL

2004-10-21 Thread Richard Huxton
[EMAIL PROTECTED] wrote:
Hello
MySQL has information about several storage engines. MEMORY to handle
temporary tables, InnoDB to handle transactions and which also can split
its table data over several files/partitions. Splitting of storage is
something which according to the following article, PostgreSQL does not
support:
http://www.devx.com/dbzone/Article/20743
But I cannot verify this due to lack of information. I haven't found any
similar information about the storage engine used by PostgreSQL which I
think is called Postgres.
PostgreSQL has one and only one storage engine. Unless you intend 
working on the source-code of PostgreSQL itself there's no point in 
enquiring about its details.

A database is already split over several files, and individual objects 
(tables/indexes) may be split into multiple files of 1GB each. You can 
spread the load over multiple drives via various RAID setups, symlinks 
or, in 8.0 tablespaces.

HTH
PS - treat most articles you read on the web with some caution. Most are 
poorly researched by people without the experience to write their topic. 
I haven't read the article linked above.

--
  Richard Huxton
  Archonet Ltd
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


Re: [GENERAL] Information about storge engine in PostgreSQL

2004-10-21 Thread Karsten Hilbert
 Splitting of storage is
 something which according to the following article, PostgreSQL does not
 support:
 
 http://www.devx.com/dbzone/Article/20743
 
 But I cannot verify this due to lack of information.
Hm. How about reading the standard PostgreSQL documentation ?
It at least depends on your definition of Splitting of
storage.

 Do you know of any places where this information can be obtained?
My guess would be the docs at the postgresql website.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [GENERAL] Information about storge engine in PostgreSQL

2004-10-21 Thread Jan Wieck
On 10/21/2004 10:27 AM, [EMAIL PROTECTED] wrote:
Hello
MySQL has information about several storage engines. MEMORY to handle
temporary tables, InnoDB to handle transactions and which also can split
its table data over several files/partitions. Splitting of storage is
something which according to the following article, PostgreSQL does not
support:
For a long time the MySQL documentation was stating that foreign keys 
are mainly for documentation purposes and explained why you really 
didn't want them and why it was so much better that MySQL swallowed 
their syntax silently without any effect. Similarly dangerous opinions 
where documented about transactions and ACID features.

Then the InnoDB table handler was added to MySQL and with the new 
features, namely transactions and referential integrity, the documented 
opinion about these features was changed. But since every other database 
had these features for long already, all that was left was now the 
capability of having different storage engines, and it became the new 
advantage feature to point out.

Right now on their boiler plate is another buzzword compliant table 
handler, the NDB cluster storage engine. And while a lot of people are 
getting all excited about it, all I really see so far is yet another 
table handler that does not provide foreign keys, that does not 
integrate with the existing transaction systems ACID properties, and 
that has outrageous network and memory requirements. Especially worried 
am I about the fact that the responsibility for referential integrity, 
that was lifted from the developers shoulders with the InnoDB tables, is 
now dropped twice as heavy back into his laps. I don't think that Web 
developers who had problems getting integrity constraints implemented in 
the application before InnoDB will do this much better in a concurrent 
multimaster cluster environment. But I am sure enough PHB's who, free 
from every knowledge obstacles, fully believe in marketing speech will 
force their developers into that nightmare.

None of all these advanced storage engines was developed by MySQL. They 
all got purchased and turned into table handlers. The multiple storage 
engine capability of MySQL is the technical base for stapling together 
those features, MySQL isn't able to build into the existing system and 
has to buy somewhere else.

The PostgreSQL philosophy is a little different. That is why we have 
only one, tightly integrated and not very easy to replace storage engine.

Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster