On Fri, Feb 14, 2014 at 9:16 PM, David Beck <db...@starschema.net> wrote: > What inspired me is the scriptable query rewrite in > http://dev.mysql.com/downloads/mysql-proxy/ > The hook I proposed would be a lot nicer in Postgres because the raw parsing > is already done at this point while in mysql-proxy that has to be done > manually.
There are a few similar things in the Postgres world such as pgbouncer and plproxy but as you note they are limited in how powerful they can be by the complexity of parsing and analyzing SQL. I think Postgres tends to take a different tack regarding extensibility than MySQL. Rather than have one system then hooks to allow external code to modify or replace it, in Postgres modules usually are treated similarly to the internal code. This is a pretty broad generalization and there are certainly exceptions. But for example new data types, functions, even whole new index types are all treated almost identically to the internal data types, functions, and index types. The planner then considers them all more or less on equal basis. Obviously there are limits. Btree indexes are kind of special because they represent Postgres's basic concept of ordering. And we don't have a pluggable recovery system which makes any externally provided index types non-crash-safe. And we don't have a generalized concept of table storage -- the closest thing we have is FDWs which is more like MySQL's style of extensibility where the extension is a special case. But this is why our instinct is that if you want to be able to push down joins the way to do it is to extend the FDW api so that the planner can make those decisions just like it makes the decisions about internal joins rather than have an external module that takes over part of the planner's work. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
