I have a SQL query like this:
SELECT * FROM database WHERE column LIKE ? ORDER BY column LIMIT 128
I would like to be able to obtain, eg, rows 129-256 of the same table. Is there a way to do this with a SQLite query?
(I could redo the same query LIMIT 256 and then skip the first 128 results before further processing, however, I feel like it would be better code to use a SQL query that simply returns the values I actually need to process.)
Add either an OFFSET clause or use two comma-separated values as the arguments of the LIMIT clause, as described in the LIMIT clause section of SQLite's syntax reference.
In other words: ... LIMIT 128 OFFSET 128, or ... LIMIT 128, 128.
Note: in the LIMIT a, b form, a is the offset and b the limit.
Related
I am sniffing out an error in my SQL query that revolves around the ARRAY_AGG function. Below are the following two lines of SQL.
The below line is the correct and complete SQL version that I ultimately want to have. This behavior is the behavior that results in a correct query.
ARRAY_TO_STRING((ARRAY_AGG(R.version ORDER BY R.released_on DESC))[1:10], ', ')
and this line here I thought would be equivalent but when I execute this line of SQL I receive ERROR: more than one row returned by a subquery used as an expression
ARRAY_TO_STRING(ARRAY_AGG((SELECT "releases"."version" FROM "releases" ORDER BY "releases"."released_on" DESC LIMIT 10)), ',')
I am arriving at this line of SQL through arel and is proving to be a little challenging but is it possible that the two lines could be equivalent? The first line is slicing an array to retrieve 10 items while the second is essentially doing the same thing albeit in rows. Could this be tweaked or will this need to be rewritten?
I haven't used ruby but it looks like the nesting in different between the two lines. Your ARRAY_AGG is getting two different sets of data.
First:
ARRAY_AGG(R.version ORDER BY R.released_on DESC)
Second:
ARRAY_AGG((SELECT "releases"."version" FROM "releases" ORDER BY "releases"."released_on" DESC LIMIT 10))
Looking there I think on your second statement is wrong, from what I see online it looks like ARRAY_AGG should be use as a column function not on a table set. Below are some links that I was looking at but I wan't sure which is correct as ARRAY_AGG looks to be a sql function and i'm not sure what flavor you are using...
https://msdn.microsoft.com/en-us/library/azure/mt763803.aspx
https://www.postgresql.org/docs/8.4/static/functions-aggregate.html
With that I think it should look like:
(SELECT ARRAY_AGG("releases"."version") FROM "releases" ORDER BY "releases"."released_on" DESC LIMIT 10)
Just a guess..
I am using MDX query to limit the huge results from my query using the following but it doesn't work. My intention is to limit the result to 10 only to reduce the loads
SELECT {[Measures].[activityduration]} ON COLUMNS,
{([rig], 10)} ON ROWS
FROM activityhours
The error says:
The following is not a valid MDX query: No function matches signature '(<Dimension>, <Numeric Expression>)'
Can anybody helps?
If you mean limit to 10 rows of rig(since you talked about huge number of records), then below should help:
SELECT {[Measures].[activityduration]} ON COLUMNS,
TOPCOUNT([rig], 10) ON ROWS
FROM activityhours
It would be first 10 values from [rig] in natural order.
What does "limit the result to 10" mean exactly? Limit to 10 rows, or do you want to filter [rig] somehow based on 10?
I've guessed you just want members of [rig] where [Measures].[activityduration] is equal to 10:
SELECT {[Measures].[activityduration]} ON COLUMNS,
[rig]
HAVING Measures].[activityduration] = 10
ON ROWS
FROM activityhours;
I would like to display 15 rows from queries but not first 15?
SELECT Abgänge.Vorgang, Abgänge.Date_SW_Drucken FROM Abgänge
WHERE Abgänge.Bezahlung = "Bar" LIMIT 34,15;
How to transform this to access 2010?
Limit:
LIMIT from_record-1, count_record
You can't, because there is no support for an offset in the Microsoft Access SELECT syntax. An option is to use TOP with offset + limit and skip offset rows manually. BTW: Using TOP or LIMIT without an ORDER BY is not advisable as it can lead to inconsistent results.
You could also combine two queries with TOP, first selecting limit + offset, and then selecting only offset, for example
SELECT TOP 15 ...
FROM (
SELECT TOP 49 ....
FROM sometable
ORDER BY somecolumn ASC
) a
ORDER BY somecolumn DESC
The only problem with this solution is that if there are less than 49 results from the subquery, then the offset will be less than 34.
If you need the result in a different order then you may need to add an additional 'layer' that applies that order.
I've got a simple select query which executes in under 1 second normally, but when I add in a contains(column, 'text') into the where clause, suddenly it's running for 20 seconds up to a minute. The table it's selecting from has around 208k rows.
Any ideas what would cause this query to run so slow with just the addition of the contains clause?
Substring matching is a computationally expensive operation. Is the field indexed? If this is a major feature implementation, consider a search-caching table so you can simply lookup where the words exist.
Depending on the search keyword and the median length of characters in the column it is logical that it would take a long time.
Consider searching for 'cookie' in a column with median length 100 characters in a dataset of 200k rows.
Best case scenario with early outs, you would do 100 * 200k = 20m comparisons
Worst case scenario near missing on every compare, you would do (5 * 100) * 200k = 100m comparisons
Generally I would:
reorder your query to filter out as much as possible in advance prior to string matching
limit number of the results if you don't need all of them at once (TOP x)
reduce the number characters in your search term
reduce the number of search terms by filtering out terms that are likely to match a lot, or not at all (if applicable)
cache query results if possible (however cache invalidation can get pretty tricky if you want to do it right)
Try this:
SELECT *
FROM table
WHERE CONTAINS((column1, column2, column3), '"*keyword*"')
Instead of this:
SELECT *
FROM table
WHERE CONTAINS(column1, '"*keyword*"')
OR CONTAINS(column2, '"*keyword*"')
OR CONTAINS(column3y, '"*keyword*"')
The first one is a lot faster.
CONTAINS does a lot of extra work. There's a few things to note here:
NVarChar is always faster, so do CONTAINS(column, N'text')
If all you want to do is see if the word is in there, compare the performance to column LIKE '%' + text + '%'.
Compare query plans before and after, did it go to a table scan? If so, post more so we can figure out why.
In ultimo, you can break up the text's individual words into a separate table so they can be indexed.
In Oracle, the number of rows returned in an arbitrary query can be limited by filtering on the "virtual" rownum column. Consider the following example, which will return, at most, 10 rows.
SELECT * FROM all_tables WHERE rownum <= 10
Is there a simple, generic way to do something similar in Ingres?
Blatantly changing my answer. "Limit 10" works for MySql and others, Ingres uses
Select First 10 * from myTable
Ref
select * from myTable limit 10 does not work.
Have discovered one possible solution:
TIDs are "tuple identifiers" or row addresses. The TID contains the
page number and the index of the offset to the row relative to the
page boundary. TIDs are presently implemented as 4-byte integers.
The TID uniquely identifies each row in a table. Every row has a
TID. The high-order 23 bits of the TID are the page number of the page
in which the row occurs. The TID can be addressed in SQL by the name
`tid.'
So you can limit the number of rows coming back using something like:
select * from SomeTable where tid < 2048
The method is somewhat inexact in the number of rows it returns. It's fine for my requirement though because I just want to limit rows coming back from a very large result set to speed up testing.
Hey Craig. I'm sorry, I made a Ninja Edit.
No, Limit 10 does not work, I was mistaken in thinking it was standard SQL supported by everyone. Ingres uses (according to doc) "First" to solve the issue.
Hey Ninja editor from Stockholm! No worries, have confirmed that "first X" works well and a much nicer solution than I came up with. Thankyou!