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

Re: About the SQL/MED Development Status and possiblitys to work with you !!!!

From: "Ing (dot) Marcos Luís Ortíz Valmaseda" <mlortiz(at)uci(dot)cu>
To: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-cluster-hackers(at)postgresql(dot)org
Subject: Re: About the SQL/MED Development Status and possiblitys to work with you !!!!
Date: 2010-03-31 17:14:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-cluster-hackers
Takahiro Itagaki escribió:
> Hi, Marcos.
> I think this discussion is very useful for all postgres developers.
> If you don't mind, we could move to pgsql-cluster-hackers(at)postgresql(dot)org(dot)
>> Why do you think that PostgreSQL's SETOF-record and MySQL's pluggable 
>> storage engine are good references to look for that?
>> Explain me this that I'm a ignorant of this topic.
>> Which ideas do you have for the implementation of these FDW modules?
> I've continued researches since that time, and I see PG's SETOF-record
> is the best references for SQL/MED; i.e, FDW should be implemented in
> executor-level pluggable modules.
> MySQL's pluggable storage engines are implemented at lower layer than it.
> They are contrasted with access methods in PostgreSQL (heap_xxx functions).
> There are trade-off in the two approach; executor-level plugins can
> optimize queries very mush if they can work together with planner.
> For example,
>     SELECT * FROM remote_tbl1, remote_tbl2 WHERE ...;
> Executor approach can send queries for remote_tbl1 and remote_tbl2
> in one query at once if they are in the same foreign server.
> On the other hand, storage-engine approach could reduce plugin's codes
> if they have low-level data access APIs, like memcached. For executor
> approach, we need to extract conditinal clause from postgres' expression
> tree by ourselves.
> I decided to use the executor approach for now, because of the former
> benefit. The latter drawback is not so big problem for FDW for remote
> PostgreSQL, that will be the most important plugin, because it can use
> existing postgres' internal APIs to handle required functionalities.
> Regards,
> ---
> Takahiro Itagaki
> NTT Open Source Software Center
I think that´s a good idea, Can you share your git branch on the 
PostgreSQL git server, to see your work and to help you
on that task.
Which other ideas do you have for the FDW plugins? For example the 
connection between SQLite and PostgreSQL ?
Or do you think that ´s not the moment to discuss this?

regards to all

Attachment: mlortiz.vcf
Description: text/x-vcard (1.5 KB)


pgsql-cluster-hackers by date

Next:From: Simon RiggsDate: 2010-03-31 19:04:29
Subject: CHAR(10) - Clustering, High Availability and Replication conference
Previous:From: Devrim GÜNDÜZDate: 2010-03-31 13:37:41
Subject: Re: Postgres-XC build error on Fedora 12

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