Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Pierre Emmanuel Gros wrote:
> In mysql, we can wrote a create table like CREATE TABLE t (i INT) ENGINE 
> 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


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



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

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group