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: 4BB38310.1040606@uci.cu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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 Content-Type Size
mlortiz.vcf text/x-vcard 1.5 KB

Responses

Browse pgsql-cluster-hackers by date

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