maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #04552
Re: request for a feature -- LIMIT_ROWS_EXAMINED
OK, will have feedback in a few days.
On Fri, Jan 20, 2012 at 6:45 AM, Timour Katchaounov
<timour@xxxxxxxxxxxxxxxx> wrote:
> Hello Mark,
>
>
>> I want a variant of the LIMIT clause that limits the number of rows
>> examined during SELECT processing. This should return OK when the
>> limit is reached -- something like NESTED_LOOP_QUERY_LIMIT. While
>> LIMIT can be LIMIT x and LIMIT x,y. This only supports one argument --
>> LIMIT_ROWS_EXAMINED x. Are you interested in implementing this feature
>> for me? We will sponsor the work. The purpose of the feature is to
>> prevent queries from taking too long when there isn't a great index
>> and many rows might be filtered.
>>
>
> After examining few alternatives, I implemented a pretty complete
> prototype of LIMIT_ROWS_EXAMINED. Please have a look at the description
> of the task here:
> https://mariadb.atlassian.net/browse/MDEV-28
>
> It is important to notice that the current implementation will stop
> execution when LIMIT_ROWS_EXAMINED is reached irrespective of the
> query execution strategies used (thus not only for JOINs, but also
> writing/reading to temp tables, sorting, and single-table access methods
> that scan too many rows). This approach also is future-proof with
> respect to adding new query processing algorithms because the counting
> is done at the handler level.
>
> The current approach is such, that it should be fairly easy to backport
> the feature to almost any MariaDB/MySQL.
>
> Please let me know if this is what you want. If so, then I will proceed
> with the remaining polishing that is in the TODO list and will get an
> internal review.
>
> You can also have a look at the small example in the comments below the
> description to get a feeling what is the behavior.
>
> I can also send you a patch of the current version in case you want to
> play with the feature before it is pushed.
>
> Timour
--
Mark Callaghan
mdcallag@xxxxxxxxx
Follow ups
References