If what you're wishing for is that you could also capture the effects
of planner steps that are in the nature of source-to-source
transformations, I think that's going to be harder because no great
effort has been made to keep those at arm's length from steps that
don't have results
On Sat, Nov 8, 2014 at 1:09 AM, mariem mariem.benfad...@gmail.com wrote:
Hi Tom,
If you don't need that, why are you insistent on extracting the
information from a plan tree?
I need to resolve expressions and apply rewrite rules before I reverse the
query plan to a query.
It seems far simpler
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 8, 2014 at 1:09 AM, mariem mariem.benfad...@gmail.com wrote:
I'm aware of ruleutils.c which I think is a good tool but I don't think it's
appropriate as it takes the parse tree as input.
Parse, Rewrite, and Plan are distinct stages.
Hi Tom,
If you don't need that, why are you insistent on extracting the
information from a plan tree?
I need to resolve expressions and apply rewrite rules before I reverse the
query plan to a query.
It seems far simpler to me to make use of ruleutils.c to reverse-list
the original parsetree.
wrote:
I don't think SQL can express the information the plan contains. For
example,
join methods (hash, nest loop, merge).
I don't need the way the query will be executed, so there is no need for
(hash, nest loop, merge).
--
View this message in context:
May be you want to check how it's done in Postgres-XC. Postgres-XC works on
plans being created by PostgreSQL and reverse-engineers queries (for
parts of the plans which are shippable.) The notions of shippability
may not be of interest to you, but the code to reverse-engineer most of
the plan
mariem mariem.benfad...@gmail.com writes:
I don't think SQL can express the information the plan contains. For example,
join methods (hash, nest loop, merge).
I don't need the way the query will be executed, so there is no need for
(hash, nest loop, merge).
If you don't need that, why are
Hello,
I would like to transform the query plan (output of the planner,
debug_print_plan) into an sql query.
I know that there are pieces of the query plan that might be machine
dependent (in var for example).
So I wanted to have your suggestions or thoughts before I put efforts into
it.
May be you want to check how it's done in Postgres-XC. Postgres-XC works on
plans being created by PostgreSQL and reverse-engineers queries (for
parts of the plans which are shippable.) The notions of shippability
may not be of interest to you, but the code to reverse-engineer most of
the plan
mariem mariem.benfad...@gmail.com wrote:
Hello,
I would like to transform the query plan (output of the planner,
debug_print_plan) into an sql query.
I don't think SQL can express the information the plan contains. For example,
join methods (hash, nest loop, merge).
--
Antonin Houska
10 matches
Mail list logo
