-
Notifications
You must be signed in to change notification settings - Fork 31
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
Impossible to suggest indexes: please enable support for pg_qualstats #123
Comments
Hello, You only need to install pg_qualstats and all the other extensions in the dedicated Are you using local setup (using the background worker and Also note that by default pg_qualstats sample 1/ |
Ok, I will mantain only in powa db.
Local setup.
I have 2 DBs that are intense read/write. Some querys: Extensions in configuration: Best regards, Alexandre |
Thanks for the details. Given the part of the queries I'm seeing and assuming a default max_connections to 100, you should have some queries that have predicates sampled. Note that pg_qualstats can only handle "simple" predicates, of the form "column operator value" or "column operator column". It will therefore ignore expression like "upper(rtrim(...)) = somevalue" for instance. Can you try to run this query on the powa database? It'll show you the databases and query that had predicates sampled recently:
If you have some results, you can then try to see if you can see anything in the UI too. |
Yep, 100 conections with an average of 30.
Returns nothing, with or without join and where: powa=# select * from powa_qualstats_quals_history_current; powa=# select * from pg_qualstats DB 16384 is the database from the pictures posted before. |
Oh, that would mean that pg_qualstats isn't processed during the snapshot. Is the table powa_qualstats_quals_history also empty? Can you show the content of the |
|
Ok, so there is nothing stored for pg_qualstats, but according to the configuration there should be something. Can you login again on the powa database, and then do:
which will force a new snapshot with extra debugging info. Can you copy/paste the output here? |
|
This is unexpected. Can you check if that query returns anything?
|
|
I see. Can you then check with this query:
|
_srvid return an error. I changed to 0:
|
Oops, yes sorry I forgot to update this one. So, it means that none of the predicates reported by pg_qualstats have a matching entry in powa_statements, which is quite surprising. Looking at the rows reported previously, can you check if the entries exist in pg_stat_statements and powa_statements:
(and also for queryid -6859641201866159772, -4267699646053293633, -202612559481739499 and 1672898585958381536, with same dbid and userid). |
Thanks for help ! |
facepalm I just realized there's a stupid typo in the query sampling pg_qualstats: You can modify the currently installed version of the stored function to fix it (for instance using Thanks a lot for the report, and sorry for taking so long to find this mistake. |
I just pushed powa-team/powa-archivist@babce62 to fix the problem. I see that you already have powa version 4.1.2, so I'm assuming that you built if from source using a recent commit. You won't be able to do an upgrade for your version 4.1.2 to current 4.1.2, so you'll have to either drop/create powa or apply this change locally. I'll try to do a release during the weekend. |
Hi ! powa=# select powa_qualstats_snapshot(0); But I still haven't the index sugestions, and need to find (in stat_statements) what queryid have predicates but is not showing too : Need I run something else ?
That is the magic behind Open Source. Your work and the team is awesome! |
Forget about this. I can see the values now. But the index sugestions in front page already showing nothing. But ok, the most important for me is the predicates. |
I'm glad that you can now see the predicate values! BTW I just released version 4.1.2 (there was some additional issue that was reported so it took a bit longer than planned). For the record, the widget on the UI tries to regenerate a full SQL query from the normalized query string stored in pg_stat_statements and the constants retrieved by pg_qualstats. But that can't work if there's something else than a qual that was normalized. In your example, the "LIMIT ?" won't be rewritten as pg_qualstats doesn't store those values, so the UI will try to run an explain on a query that still has the "LIMIT ?" part ending up with an error as this is invalid SQL.
Which widget are you talking about? The global index suggestion in the per-database page on the per-query one? |
Great news Julien
is 4.1.2 available from pip to install?
нд, 20 груд. 2020 о 20:33 Julien Rouhaud <notifications@github.com> пише:
… I'm glad that you can now see the predicate values! BTW I just released
version 4.1.2 (there was some additional issue that was reported so it took
a bit longer than planned).
For the record, the widget on the UI tries to regenerate a full SQL query
from the normalized query string stored in pg_stat_statements and the
constants retrieved by pg_qualstats. But that can't work if there's
something else than a qual that was normalized. In your example, the "LIMIT
?" won't be rewritten as pg_qualstats doesn't store those values, so the UI
will try to run an explain on a query that still has the "LIMIT ?" part
ending up with an error as this is invalid SQL.
But the index sugestions in front page already showing nothing
Which widget are you talking about? The global index suggestion in the
per-database page on the per-query one?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIHWEYBD6IVYRZZF4CHNTGLSV3FZDANCNFSM4U53T5SA>
.
|
Hi @banlex73 |
Hi Julien,
Great, I will upgrade.
I undestand, but I don't know why some querys still have no predicates:
Global in per-database (actualy I created this issue because this): Best regards, Alexandre |
The problem with that query is that is has OR-ed predicates. pg_qualstats will ignore them as there's no way to know how much each of the predicate of the OR-ed list impact the metrics for the global expression. If there are parts of the expression that aren't affected by any OR, they should however be sampled, although in that case I'm not sure that the metrics gathered would make much sense. You could also try to temporarily set pg_qualstats.sample_rate to 1 to make sure that all the query are sampled by pg_qualstats. For the index suggestion, there's an issue in the extension version detection for local server, which I unfortunately didn't test lately. I'll release a new version to fix it. In the meantime, if you can apply local change, the following diff should fix it:
|
Ok, I will try this.
Awesome work, Julien ! Thanks ! |
thank you very much for clarification
пн, 21 груд. 2020 о 00:33 Julien Rouhaud <notifications@github.com> пише:
… Hi @banlex73 <https://github.com/banlex73>
There's no update in powa-web or powa-collector, only the powa-archivist
extension. It's because the bugs are in the data collection part only. So
you can keep using the already released pypi packages for everything else.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIHWEYDMKPVGY5RVPLH2PELSV4B4HANCNFSM4U53T5SA>
.
|
I'm closing this issue now that v4.1.1 has been released with that fix! |
Hi,
Using Postgresql 13.1 from sources.
I compiled powa, pg_qualstat, pg_stat_kcache and install powa-web 4.1 via pip3 (debian 10).
Config this extensions in preload, create powa db locally and create extensions on that:
powa=# \dx
List of installed extensions
Name | Version | Schema | Description
--------------------+---------+------------+------------------------------------------------------------------------
btree_gist | 1.5 | public | support for indexing common datatypes in GiST
pg_qualstats | 2.0.2 | public | An extension collecting statistics about quals
pg_stat_kcache | 2.2.0 | public | Kernel statistics gathering
pg_stat_statements | 1.8 | public | track planning and execution statistics of all SQL statements executed
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
powa | 4.1.2 | public | PostgreSQL Workload Analyser-core
Everthing is OK with powa-web, but index sugestions and predicates for a query shows nothing.
Should I have to do CREATE EXTENSION in every database or only on powa (I do this for one of my DB, with no change) ?
Best regards and thank you for this great software !
The text was updated successfully, but these errors were encountered: