sql-execution-plan

When using EXPLAIN QUERY PLAN in SQLite 3 it sometimes gives me output such as SEARCH TABLE staff AS s USING AUTOMATIC COVERING INDEX (is_freelancer=? AND sap=?) (~6 rows) Where does the index come from and what does it do? The table has no manually created indices on it. "Automatic" means that SQLite creates a temporary index that is used only for this query, and deleted afterwards. This happens when the cost of creating the index is estimated to be smaller than the cost of looking up records in the table without the index. (A covering index is an index that contains all the columns to be

we have a few tables storing temporal data that have natural a primary key consisting of 3 columns. Example: maximum temperature for this day. This is the Composite Primary key index (in this order): id number(10): the id of the timeserie. day date: the day for which this data was reported kill_at timestamp: the last timestamp before this data was deleted or updated. Simplified logic: When we make a forecast at 10:00am, then the last entry found for this id/day combination has his create_at changed to 9:59am and the newly calculated value is stored with a kill_at timestamp of '31.12.2999'.

What will be the sequence of execution followed by SQL if a query has both group by and order by clause. Does it depend on their position in the query??? ORDER BY always executes on the results of the grouping performed by GROUP BY , i.e., always "after". In standard SQL, you must have ORDER BY lexically after GROUP BY , if both are present, to kind of "remind you" of the fact. in order: FROM & JOIN s determine & filter rows WHERE more filters on the rows GROUP BY combines those rows into groups HAVING filters groups ORDER BY arranges the remaining rows/groups It depends on many things

Is this an Oracle 12c bug? I run 64-bit Oracle 12.1.0.2 on Oracle Linux. Came across a strange thing: when the execution plan switches to using "PARTITION LIST SUBQUERY" then the package used in the affected query is loosing all of its variable's values. It looks like something de-instantiates the package just like after running DBMS_SESSION.RESET_PACKAGE. The query uses a partitioned table which partitions are limited by joining with another table limited using a variable from the package read using a deterministic "getter" function. If I change the function not to be deterministic, or change

I stumbled upon with a very curious case. We have a SQL Server 2012 database and such a table CREATE TABLE [dbo].[ActiveTransactions] ( [Id] [BIGINT] IDENTITY(1,1) NOT NULL, [Amount] [DECIMAL](12, 4) NOT NULL, [TypeId] [SMALLINT] NOT NULL, [GameProviderId] [SMALLINT] NULL, [UserId] [INT] NOT NULL, [Checksum] [NVARCHAR](150) NOT NULL, [Date] [DATETIME2](7) NOT NULL, [ExternalKey] [VARCHAR](60) NULL, [ExternalDescription] [NVARCHAR](1000) NULL, [OperatorId] [SMALLINT] NULL, [GameId] [NVARCHAR](50) NULL ) This table has multiple indexes but the two which I want to talk about here are PK

My applications runs queries against a sql server database. In many cases I can see the benefit of an execution plan: for example I click for the first time on a button to SELECT * from Tasks WHERE IdUser = 24 AND DATE < '12/12/2010' and DATE > '01/01/2010' it takes 15 seconds the first time, 8 seconds the following times. EDIT: I USE PARAMETRIZED QUERIES. So I have a 7 seconds improvement the second time. Now as I run the application again (so I do a new database connection) the first time it will take 15 seconds, the second time 7... How is it possible to tell SQL Server to store the

My Query: EXPLAIN EXTENDED SELECT `artwork`.`id` , `artwork`.`added` FROM `artwork` ORDER BY `artwork`.`added` DESC LIMIT 0 , 6 When I added an index on "added" to avoid using filesort and use index instead the output of explained went from id select_type table type possible_keys key key_len ref rows filtered Extra 1 SIMPLE artwork ALL NULL NULL NULL NULL 302 100.00 Using filesort to id select_type table type possible_keys key key_len ref rows filtered Extra 1 SIMPLE artwork index NULL added 4 NULL 6 5033.33 and I'm concerned about the filtered going up approximently 4,100 - I can't find on

Assuming that a table contains sufficient information to warrant an index seek, at what cardinality will SQL Server (or PostgreSQL) opt for an index scan? The reason I ask this is I previously posted a question ( link ) in which two queries performed at the same speed, yet one didn't attempt to use the index on the processed columns. After SQL Server suggested I put a covering index that included the columns being queried (it suggested this for both queries), I started looking for reasons as to why it would make such a strange suggestion. I experimented with making the indexes covering and