Re: New hook after raw parsing, before analyze

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Beck <dbeck(at)starschema(dot)net>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New hook after raw parsing, before analyze
Date: 2014-02-13 20:22:17
Message-ID: 19329.1392322937@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Beck <dbeck(at)starschema(dot)net> writes:
> I have table like data structures in the source system for the FDW I work on.
> These tables are sometimes too big and the source system is able to filter and join them with limitations, thus it is not optimal to transfer the data to Postgres.
> At the same time I want the users to think in terms of the original tables.

> The idea is to rewrite the SQL queries like this:

> SELECT * FROM tableA a, tableB b WHERE a.id=b.id AND a.col1=1234 AND b.col2=987

> to:

> SELECT * FROM fdw_tableA_tableB ab WHERE ab.col1=1234 AND ab.col2=987

TBH this sounds like a spectacularly bad idea, especially in the place and
way you propose to do it. You can't even do catalog access safely where
you've put that hook, not to mention that there are many other places
where queries can be submitted. But more generally, an FDW should not
operate in the way you're describing.

We do lack support for pushing joins to the foreign server, and that needs
to be addressed; but we need to do it in the planner, not by kluging the
query somewhere upstream of that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-02-13 20:34:09 Re: Auto-tuning work_mem and maintenance_work_mem
Previous Message Greg Stark 2014-02-13 20:00:38 Re: Recovery inconsistencies, standby much larger than primary