Commit graph

11 commits

Author SHA1 Message Date
Marko Mäkelä
270eeeb523 Merge 10.5 into 10.6 2023-05-23 12:25:39 +03:00
Monty
92d2ceac73 MDEV-28285 Unexpected result when combining DISTINCT, subselect and LIMIT
The problem was that when  JOIN_TAB::remove_duplicates() noticed there
can only be one possible row in the output, it adjusted limits but
didn't take into account any possible offset.

Fixed by not adjusting limit offset when setting one-row-limit.
2023-05-23 09:16:36 +03:00
Marko Mäkelä
21778b8aa8 Merge 10.5 into 10.6 2022-01-20 07:39:11 +02:00
Sergei Petrunia
7259b299a5 MDEV-27382: OFFSET is ignored when combined with DISTINCT
A query in form

  SELECT DISTINCT expr_that_is_inferred_to_be_const LIMIT 0 OFFSET n

produces one row when it should produce none. The issue was in
JOIN_TAB::remove_duplicates() in the piece of logic that tried to
avoid duplicate removal for such cases but didn't account for possible
"LIMIT 0".

Fixed by making Select_limit_counters::set_limit() change OFFSET to 0
when LIMIT is 0.
2022-01-19 14:04:10 +03:00
Vicențiu Ciorbaru
299b935320 MDEV-23908: Implement SELECT ... OFFSET ... FETCH ...
This commit implements the standard SQL extension
OFFSET start { ROW | ROWS }
[FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES }]

To achieve this a reserved keyword OFFSET is introduced.

The general logic for WITH TIES implies:
1. The number of rows a query returns is no longer known during optimize
   phase. Adjust optimizations to no longer consider this.
2. During end_send make use of an "order Cached_item"to compare if the
   ORDER BY columns changed. Keep returning rows until there is a
   change. This happens only after we reached the row limit.
3. Within end_send_group, the order by clause was eliminated. It is
   still possible to keep the optimization of using end_send_group for
   producing the final result set.
2021-04-21 14:09:14 +03:00
Vicențiu Ciorbaru
2d595319bf cleanup: Select_limit_counters rename set_unlimited to clear
The function was originally introduced by eb0804ef5e
MDEV-18553: MDEV-16327 pre-requisits part 1: isolation of LIMIT/OFFSET handling

set_unlimited had an overloaded notion of both clearing the offset value
and the limit value. The code is used for SQL_CALC_ROWS option to
disable the limit clause after the limit is reached, while at the same
time the calling code suppreses sending of rows.

Proposed solution:
Dedicated clear method for query initialization (to ensure no garbage
remains between executions).
Dedicated set_unlimited that only alters the limit value.
2021-04-21 14:08:58 +03:00
Vicențiu Ciorbaru
5e72099b83 cleanup: Delete unused function Select_limit_counters::is_unrestricted 2021-04-21 14:08:58 +03:00
Vicențiu Ciorbaru
13cf8f5e9a cleanup: Refactor select_limit in select lex
Replace
  * select_lex::offset_limit
  * select_lex::select_limit
  * select_lex::explicit_limit
with select_lex::Lex_select_limit

The Lex_select_limit already existed with the same elements and was used in
by the yacc parser.

This commit is in preparation for FETCH FIRST implementation, as it
simplifies a lot of the code.

Additionally, the parser is simplified by making use of the stack to
return Lex_select_limit objects.

Cleanup of init_query() too. Removes explicit_limit= 0 as it's done a bit later
in init_select() with limit_params.empty()
2021-04-21 14:08:58 +03:00
Oleksandr Byelkin
ebeb4f93e8 MDEV-16327: Server doesn't account for engines that supports OFFSET on their own.
Engine get LIMIT/OFFSET info an can it use/reset.
2019-10-13 09:40:41 +02:00
Oleksandr Byelkin
1ae02f0e0d MDEV-18553: MDEV-16327 pre-requisits part 2: uniform of LIMIT/OFFSET handling
Now both offset and limit are stored and do not chenged during execution
(offset is decreased during processing in versions before 10.5).

(Big part of this changes made by Monty)
2019-10-13 09:40:41 +02:00
Oleksandr Byelkin
eb0804ef5e MDEV-18553: MDEV-16327 pre-requisits part 1: isolation of LIMIT/OFFSET handling 2019-10-13 09:40:41 +02:00