Re: [Maria-developers] request for a feature -- LIMIT_ROWS_EXAMINED
A warning would be excellent. An error would be a problem. Returning OK is probably not the best result when the examined limit is reached. On Wed, Dec 21, 2011 at 7:17 AM, Timour Katchaounov <timour@montyprogram.com> wrote:
Hi!
> "MARK" == MARK CALLAGHAN<mdcallag@gmail.com> writes:
MARK> I want a variant of the LIMIT clause that limits the number of rows MARK> examined during SELECT processing. This should return OK when the MARK> limit is reached -- something like NESTED_LOOP_QUERY_LIMIT. While MARK> LIMIT can be LIMIT x and LIMIT x,y. This only supports one argument -- MARK> LIMIT_ROWS_EXAMINED x. Are you interested in implementing this feature MARK> for me? We will sponsor the work. The purpose of the feature is to MARK> prevent queries from taking too long when there isn't a great index MARK> and many rows might be filtered.
I am a bit afraid of returning 'ok'. Would it not be better to return an error?
Another option would be to generate a warning so that the application can know that they didn't get all rows.
This is what I would prefer to do: - process the new LIMIT_ROWS_EXAMINED clause in the same way as LIMIT, just with a different condition to end query execution, - in addition produce a warning that not all rows were returned.
Mark, does the above suit you? If you don't want to check for warnings, you can skip them, however users will have the option to detect that not all rows were returned.
Timour
We can do this and it should be relatively easy to do.
Regards, Monty
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com
This looks like a good alternative to the load shedding scripts that a lot of people run. On Dec 21, 2011 10:02 AM, "MARK CALLAGHAN" <mdcallag@gmail.com> wrote:
A warning would be excellent. An error would be a problem. Returning OK is probably not the best result when the examined limit is reached.
On Wed, Dec 21, 2011 at 7:17 AM, Timour Katchaounov <timour@montyprogram.com> wrote:
Hi!
>> "MARK" == MARK CALLAGHAN<mdcallag@gmail.com> writes:
MARK> I want a variant of the LIMIT clause that limits the number of
rows
MARK> examined during SELECT processing. This should return OK when the MARK> limit is reached -- something like NESTED_LOOP_QUERY_LIMIT. While MARK> LIMIT can be LIMIT x and LIMIT x,y. This only supports one argument -- MARK> LIMIT_ROWS_EXAMINED x. Are you interested in implementing this feature MARK> for me? We will sponsor the work. The purpose of the feature is to MARK> prevent queries from taking too long when there isn't a great index MARK> and many rows might be filtered.
I am a bit afraid of returning 'ok'. Would it not be better to return an error?
Another option would be to generate a warning so that the application can know that they didn't get all rows.
This is what I would prefer to do: - process the new LIMIT_ROWS_EXAMINED clause in the same way as LIMIT, just with a different condition to end query execution, - in addition produce a warning that not all rows were returned.
Mark, does the above suit you? If you don't want to check for warnings, you can skip them, however users will have the option to detect that not all rows were returned.
Timour
We can do this and it should be relatively easy to do.
Regards, Monty
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Hi!
"MARK" == MARK CALLAGHAN <mdcallag@gmail.com> writes:
MARK> A warning would be excellent. An error would be a problem. Returning MARK> OK is probably not the best result when the examined limit is reached. Ok, we will try to develop this feature (with a ok + warning) this year. (Should not be that many hours of work). Regards, Monty
Yes, I don't think it is a lot of work. I started on it myself but don't trust myself to modify optimizer code. I think we can find a bigger project to collaborate on in 2012 -- probably something related to replication. On Wed, Dec 21, 2011 at 12:57 PM, Michael Widenius <monty@askmonty.org> wrote:
Hi!
"MARK" == MARK CALLAGHAN <mdcallag@gmail.com> writes:
MARK> A warning would be excellent. An error would be a problem. Returning MARK> OK is probably not the best result when the examined limit is reached.
Ok, we will try to develop this feature (with a ok + warning) this year. (Should not be that many hours of work).
Regards, Monty
-- Mark Callaghan mdcallag@gmail.com
participants (3)
-
Eric Bergen -
MARK CALLAGHAN -
Michael Widenius