Closed jakubwartakEDB closed 1 month ago
So , is it possible to hint with estimation a query with duplicate aliases inside? (even though internally optimizer renames those?)
Don't think so as contrary to Oracle that enforces the hint to be after SELECT or one of the three DML keywords, pg_hint_plan can only define a single hint placed anywhere in the query, fails if there is a second hint string, and cannot attach the context of a query to a given hint.
Short answer: no by design, I am afraid.
Hi, I'm trying to use pg_hint_plan to hint estimations using the Rows() hint in case of duplicate rel aliases? E.g. given the sample like this:
[..] -> got 1234 so it works (it was a sanity check).
Lets start introducing aliases:
[..] -> ok, it doesn't work because as per docs we need aliases if those are used (it's fair). So let's switch to hinting aliases:
[..] -> it worked, cool.
OK, but now the main problem enters the stage - let's change query to have duplicate aliases:
[..] -> ok, it's fair
Enter duplicate aliases
And we cannot use /+ Rows(t1 t2 #1234) / as per above and thus need to use aliases (but they are duplicate...), so let's try ANY_subquery just for start
[..] -> thus ANY_subquery is not helping here
Also , the optimizer was free and renamed b to b_1 as per above, so let's try hint it using that :
[..] -> it's not used... why?
I've cannot also reference the "b" as it is ambiguous
So i've added some little elog(bmsToString() at the start of make_join_rel() to see how code is launched , but it says:
So , is it possible to hint with estimation a query with duplicate aliases inside? (even though internally optimizer renames those?)