We noticed MSTR Query for Redshift was added the limit clause at the end, like 'LIMIT 600001', without our intention. Not with all the query, but costly query tends to have it automatically.
We'd like to clarify what configure makes this at Redshift or MicroStrategy.
If my memory serves me correctly, right after our migration to Redshift 8 months ago, we didn't notice such a limitation.
Any information would be highly appreciated.
Check the query in MSTR.
If you see LIMIT this MSTR and you should check VLBD properties.
Related
I want to Tune my PostgreSQL stored procedure which has 1000 queries Inside. My SP is suddenly started to lack Perfomance.
How can I debug this SP which query is lagging performance inside the SP? Since Explain analyze doesn’t really show the much stats on SP.
Thanks for you help out
You best use auto_explain with auto_explain.log_nested_statements, auto_explain.log_analyze and auto_explain.log_buffers turned on.
Then you get the execution plans of all SQL statements with their duration logged.
I think that if you have a single function with 1000 different SQL statements inside, your design could be improved.
I have a performance drop once in a couple of days. When I manually analyze a table, the performance is back to normal. The table to be analyzed has 2.7M records. The query is very complex, uses a lot of different tables, unions and joins. The view I query just aggregates some data from another view. If I query the main -aggregated- view, it takes about 1.5-3.5 secs. If I query the view one level higher, it takes only 0.2s.
This issue occured when migrated from 9.5 to 12.3. Analyzing one specific table solves it for a couple of days.
Autoanalyze never occurs automatically, so there seems no need to autoanalyze. But the query planner goes wrong somehow. I've increased the statistics_target in the config to 1500.
We never had this issue on 9.5. Maybe it has something to do with the JIT, but disabling it in the session does not seem to solve the issue.
I use grafana to view metrics in timescaledb.
For large scale metrics I create a view to aggregate them to a small dataset, I configure a sql in grafana, which table is fixed, I want the table name is changed according to the time range, say: time range less than 6 hours, query the detail table, time range greater than 24 hours query the aggregate view.
So I am looking for a proxy or postgresql plugin which can used to modify the sql before execute it.
AFAIK there is no PostgreSQL extension to modify SQL query but there is a proxy that says it can rewrite and filter SQL query: https://github.com/wgliang/pgproxy.
You might alternatively look at TimescaleDB's real-time aggregates, which were released in 1.7
Basically it will transparently take the "union" between pre-calculated aggregates > 6 hours with the "raw" data < 6 hours.
Not quite what you are asking for, but might get you to the same place, and works transparently with grafana.
https://blog.timescale.com/blog/achieving-the-best-of-both-worlds-ensuring-up-to-date-results-with-real-time-aggregation/
I would suggest taking a look at Gallium Data, it's a free database proxy that allows you to change database requests before they hit the database, and database responses before they reach the clients.
Disclosure: I'm the founder of Gallium Data.
I've got PostgreSQL 9.2 and a tiny database with just a bit of seed data for a website that I'm working on.
The following query seems to run forever:
ALTER TABLE diagnose_bodypart ADD description text NOT NULL;
diagnose_bodypart is a table with less than 10 rows. I've let the query run for over a minute with no results. What could be the problem? Any recommendations for debugging this?
Adding a column does not require rewriting a table (unless you specify a DEFAULT). It is a quick operation absent any locks. pg_locks is the place to check, as Craig pointed out.
In general the most likely cause are long-running transactions. I would be looking at what work-flows are hitting these tables and how long the transactions are staying open for. Locks of this sort are typically transactional and so committing transactions will usually fix the problem.
Our team is working on a Postgresql database with lots of tables and views, without any referential constraints. The project is undocumented and there appears to be a great number of unused/temporary/duplicate tables/views dirtying the schema.
We need to discover what database objects have real value and are actually used and accessed.
My inital thoughts were to query the Catalog/'data-dictionary'.
Is it possible to query the Postgresql Catalog to find an object's last query time.
Any thoughts, alternative approaches and or tools ideas?
Check the Statistics Collector
Not sure about the last query time but you can adjust your postgresql.conf to log all SQL:
log_min_duration_statement = 0
That will at least give you an idea of current activity.
Reset the statistics, pg_stat_reset(), and then check the pg catalog tables like pg_stat_user_tables and such to see where activity looks like its showing up.