On 5/3/07, MB Software Solutions <[EMAIL PROTECTED]> wrote:
> Question: rather than just blindly run this, would it be better
> performancewise I wonder if I should do a SELECT first to see if any
> such records exist prior to calling the update sql? Example (after
> dynamically built):
The fas
Ya roll the dice ... Just kidding.
This is why we're going to repeat some of the sessions in the third
room. Too many good sessions going up against each other. Hopefully
this will help.
-Kevin
CULLY Technologies, LLC
Sponsor of FoxForward 2007
foxforward.net
MB Software Solutions wrote:
>
Steve Ellenoff wrote:
> AFAIK Limit is applied last, just as you said. Explain is more for
> determining what indexes (or lack thereof) a certain query is using.
>
> Glad to hear I'll have at least 1 attendee! :)
>
>
Two! (Assuming my session isn't at the same time as yours?)
--
Michael J.
AFAIK Limit is applied last, just as you said. Explain is more for
determining what indexes (or lack thereof) a certain query is using.
Glad to hear I'll have at least 1 attendee! :)
At 12:59 PM 5/3/2007, Kevin Cully wrote:
>I would think that it would be faster doing one SPT to MySQL than to
Kevin Cully wrote:
> In fact, after a quick test with a query that was not optimized on an
> index, the LIMIT time took longer.
>
> SELECT ordPK, ordFinalDisposition FROM tblOrders WHERE
> ordFinalDisposition='In Process' ORDER BY ordPK
>
> The above select took 0.29 seconds. The EXPLAIN indicated
In fact, after a quick test with a query that was not optimized on an
index, the LIMIT time took longer.
SELECT ordPK, ordFinalDisposition FROM tblOrders WHERE
ordFinalDisposition='In Process' ORDER BY ordPK
The above select took 0.29 seconds. The EXPLAIN indicated that it was
using the WHERE, a
Kevin Cully wrote:
> Look at the ROWS column when doing an EXPLAIN before your select
> statement. I believe the speed comes from matching the index(es) and
> not necessarily from the LIMIT. I may be (very) wrong though.
>
Oh I agree that the speed comes from the matching indexes...for
sure.
Look at the ROWS column when doing an EXPLAIN before your select
statement. I believe the speed comes from matching the index(es) and
not necessarily from the LIMIT. I may be (very) wrong though.
Nothing is going to be as fast as a SEEK, but I sure like the features
of a SQL Server. I'm very p
Kevin Cully wrote:
> I would think that it would be faster doing one SPT to MySQL than to do
> multiple hits. I'm trying to remember but I believe that the LIMIT is
> done last, after the select so it really isn't a performance booster
> that you might think.
>
Wow...I'll have to research that
I would think that it would be faster doing one SPT to MySQL than to do
multiple hits. I'm trying to remember but I believe that the LIMIT is
done last, after the select so it really isn't a performance booster
that you might think.
I think between using EXPLAIN, and doing some sample tests, that
Here's my built lcSQL string:
lcSQL = [update addresses set iactive = 0 where iacctid = ]
+ ALLTRIM(STR(toRecord.iacctid)) + [ and caddrtype = '] + ;
ALLTRIM(toRecord.cAddrType) + [' and iactive = 1]
Question: rather than just blindly run this, would it be bette
11 matches
Mail list logo
