Re: storage engine , mysql syntax CREATE TABLE t (i INT)

From: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
To: Pierre Emmanuel Gros <Pierre-Emmanuel(dot)Gros(at)limsi(dot)fr>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: storage engine , mysql syntax CREATE TABLE t (i INT)
Date: 2004-07-29 11:55:15
Message-ID: 4108E5A3.70605@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pierre Emmanuel Gros wrote:
> In mysql, we can wrote a create table like CREATE TABLE t (i INT) ENGINE
> = INNODB||BDB|;
> where the storage engine is the innodb one. This allow to have
> differents kind of storage format, and allow to easly implements memory
> table or remote table. I try to make the same thing for postgresql but i
> do not understand where the logical storage engine is in the source code.
> May i have somme help to find it .
> Thank you.
> pierre

Pierre,

Basically the code related to the storage engine can be found in
src/backend/storage. There you will find some important parts of
PostgreSQL such as the free space map, the lock manager and so forth.
The storage system is implemented there. The code should be extendable
although nobody has implemented different storage systems in the past
(at least I can't remember) because it has never been important.

Personally I don't think that real memory tables are important. In 7.5
you can even model them with the help of RAM drives and tablespaces (in
case you really need it).

As far as remote tables are concerned: To do database links properly you
will need some mutli-phase commit algorithm. I don't think it is that
easy. How would you ensure integrity? Did you already think about
transaction isolation related issues? How would the planner treat those
issues and how should recovery in case of disaster work? Recall, you are
in a distributed system then ...

Regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeroen T. Vermeulen 2004-07-29 11:56:23 Re: try/catch macros for Postgres backend
Previous Message Gaetano Mendola 2004-07-29 11:38:08 extra info on autovaccum log