-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syntax error on a correct query #96
Comments
Hi, On which widget(s) do you get this error? |
On Predicates, in Example values |
I see. What it means is that powa couldn't find a stored predicate for that query in the given time interval, and had a fallback on just using the raw pg_stat_statements query. On postgres 16 and above the solution would be to rely on the GENERIC_PLAN option, but I don't think that you have such a version. |
Postgres 16 is here psql (16.6 (Debian 16.6-1.pgdg110+1)) But for some reason I don't see any stored predicates at all |
Can I check something to clarify the situation? |
Well, it's not unexpected to not see any predicate for a given query, that depends on your workload and how pg_qualstats is configured (by default it samples 1/ |
Okay, I need to check pg_qualstats and find out if I'm doing something wrong and nothing is stored there? Any ideas how to check why GENERIC_PLAN is not used? |
GOT IT!!! Some statements are recorded as "select * from table where field is ?" GENERIC_PLAN fails on it, expecting "select * from table where field is $1" So what should I do next? |
Because we didn't implement it. That's on the list but with the recent version 5 we have been busy fixing the bugs introduced in the v4 -> v5. Once everything is stable we will start again adding new feature, such as this one
I think that the statements are recorded as |
Okay, can I do something with this? |
All contributions are welcome. I think that some big improvements are needed on those widgets though. The initial idea was to be able to compare execution plan with different "kind of predicates" (most filtering, less filtering and so on), as a way to see if it impacts decision on indexes or something. For instance if the most filtering predicates could benefit from an index but not the least filtering, but if the least filtering is also the less frequent or is just a single value then you can maybe create a partial index or something like that. The per-predicate statistic page is also meant to help for that. Anyway, if we can't get the specific kind of predicate, it's not really useful to still try to get an explain plan since it doesn't bring information, and instead we should return explanation about the issue (no qual found, other problem or something). |
Running POWA 5, I've got an error
The request is long but straightforward
The request looks correct and is executed without a problem
The text was updated successfully, but these errors were encountered: