When I execute a query and right click in the results area, I get a pop-up menu with the following options:
Save Grid as Report ...
Single Record View ...
Count Rows ...
Find/Highlight ...
Export ...
If I select "Count Rows", is there a way to interrupt the operation if it starts taking too long?
No, you don't seem to be able to.
When you select Count Rows from the context menu, it runs the count on the main UI thread, hanging the whole UI, potentially for minutes or hours.
It's best not to use that feature - just put select count (*) from ( < your query here>) which it runs properly on separate thread which can be cancelled.
You can open an new instance of sql developer and kill the session counting the rows.
I do suggest using the select count(*) query though as it is less painful in the long run.
Related
I have a Postgres materialized view that gets refreshed every night - a fairly large dataset. The first time someone tries to run it after a refresh, the query takes 9-10 minutes. After that, queries return in their usual 1-2 seconds.
SELECT * FROM MyMaterializedView
WHERE response_time BETWEEN '2022-01-01' AND '2022-02-01'
AND property_id = 123
...and there is an index on the Materialized View for the response_time and property_id columns.
My question is - is it normal for the initial running of a materialized view to take so much longer, and is there a way to handle this in the refresh to prevent the initial long-running query?
I can think of two possible reasons:
the data are not cached the first time you query the materialized view
the first query has to set the “hint bits” on all the rows it selects
You should set track_io_timing = on and run EXPLAIN (ANALYZE, BUFFERS) SELECT ... on your query to know for sure. If it is the first problem, you will see lots of buffers read and a high I/O time, in the second case you'll see lots of buffers dirtied or buffers written.
I have a query from another thread which goes through a list of different events and pulls out the most recent event and puts it into a list. The code I'm using is:
SELECT Cleaning1, Max(Date1) AS most_recent
FROM CleaningLog
GROUP BY Cleaning1;
Cleaning1 is the column that has the different cleanings, and Date1 is the column that has the date the cleaning occurred, and CleaningLog is the name of the table. I currently have a macro in Access which is an OpenQuery, query. I am having it open the above query, and then having it view as a data sheet and it's in edit mode.
What I am stuck on, is getting a subsequent macro/query/vba code to take the datasheet the query produces and going through each item and determining if they're over due to be cleaned. I tried having a Make Table query, but the problem is, there is no user friendly way to refresh that table without having to delete it (I am having unskilled workers use this Access sheet).
I am wondering if there's a way to look at the most recent cleaning's date, what the query produces, and filter the dates out that are over due for a cleaning, specified by a parameter. I have been looking at this webpage to start playing with the notation, but I haven't been able to come up with much that is useful.
https://support.office.com/en-us/article/Examples-of-query-criteria-3197228C-8684-4552-AC03-ABA746FB29D8
Another problem that I am encountering is that each cleaning doesn't have the same time frame in which is needs to be cleaned.
Thank you in advance for any help!!
You should just be able to modify the query above to show entries with a max date lower than they should be. Below shows entries that haven't been cleaned in 30 days, for instance.
SELECT Cleaning1, Max(Date1) AS most_recent
FROM CleaningLog
GROUP BY Cleaning1
HAVING Max(Date1) < Now() - 30;
I just started using MySQL Workbench (6.1). The default limit for queries is 1,000 and that's fine I want to keep that.
But the results from the action output message will therefore always say "1000 rows returned".
Is there a setting to see the number of records that would be returned in the query had their been no limit? For sanity checking query results?
I know this is late by a few years, but I think you're asking for a way to see total row count in the bottom of the results pane, like in SQL Server. In SQL Server, you would also go in the messages pane and it would say how many rows were returned. I was actually looking for exactly what you were asking for as well, and seems like there is no way to find that. If you have an ID in your table that is just numeric and is in numeric order, you could order by ID desc and look at the biggest number there. That is what I've decided to do.
The result is not always "1000 rows returned". If there are less records than that you will get the actual count. If you want to know the total number of rows in a table do a select count(*) from table. Alternatively, you can switch off the automatic limit and have all records returned by MySQL Workbench, but that can be time + memory consuming for large tables.
I think removing the row limit will help. By default, MySQL workbench will limit the result set to 1000 rows but you can always disable the limit. Check out https://superuser.com/questions/240291/how-to-remove-1000-row-limit-in-mysql-workbench-queries on how to do that.
You can run a second query to check that
select count(*) from (your original query) as t;
this will return the total rows in actual result.
You can use the SQL count function. It returns the count of the total number of rows a query returns.
A sample query:
select count(*) from tableName where field1 = value1
In workbench, in the dropdown menu at the top, set it to dont limit Then run the query to extract data from table Then under the output pane below, the total count of the query results will be displayed in the message column
I have an BPM application where I am polling some rows from DB2 database at every 5 mins with a scheduler R1 with below query -
- select * from Table where STATUS = 'New'
based on rows returned I do some processing and then change the status of these rows to 'Read'.
But while this processing is being completed, its takes more than 5 mins and in meanwhile scheduler R1 runs and picks up some of the cases already picked up in last run.
How can I ensure that every scheduler picks up the rows which were not selected in last run. What changes do i need to do in my select statement? Please hep.
How can I ensure that every scheduler picks up the rows which were not selected in last run
You will need to make every scheduler aware of what was selected by other schedulers. You can do this, for example, by locking the selected rows (SELECT ... FOR UPDATE). Of course, you will then need to handle lock timeouts.
Another option, allowing for better concurrency, would be to update the record status before processing the records. You might introduce an intermediary status, something like 'In progress', and include the status in the query condition.
When you perform a SELECT over a large table in SQL Management Studio by default, the result is displayed in a Grid table. As we can imagine, when the result set is million lines long, the data will be fed to that table widget that is displayed in SQL Management Studio.
Will that have an impact on the execution duration of the query ?
If so, is it possible to disable the displaying of the results of the query, to get a more realistic execution time of that query ?
UPDATE :
When I say display, I don't mean "Display ... Execution Plan" but the display of the data on the screen
there are 3 ways to display resultset in management studio
results to text
results to grid
results to file
you can choose option 1 and chk execution time and compare it with option 2 execution time.