>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 descri
Robert Haas writes:
> On Sat, Nov 8, 2014 at 1:09 AM, mariem 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. ruleutils.c takes
> the tree that results
On Sat, Nov 8, 2014 at 1:09 AM, mariem 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 to me to make u
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.
mariem 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 you insistent on extrac
>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
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:
http://postgresql.1045698.n5.nab
mariem 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
Cybertec Schönig & Schönig
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 p
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.
Basicall
10 matches
Mail list logo
