sqlite single transaction without foreign key or triggers
rtw at freenet.co.uk
Thu May 14 00:46:16 CEST 2009
John Machin wrote in news:b722bd36-c8f1-4cdf-8625-2550cee21511
@i28g2000prd.googlegroups.com in comp.lang.python:
> On May 13, 11:46 am, a... at pythoncraft.com (Aahz) wrote:
>> In article <Xns9C09513903E8FrtwfreenetREMOVEc... at 220.127.116.11>,
>> Rob Williscroft <r... at freenet.co.uk> wrote:
>> >Aahz wrote innews:guao50$1jv$1 at panix3.panix.comin comp.lang.python:
>> >> In article <Xns9C08E179B66D8rtwfreenetREMOVEc... at 18.104.22.168>,
>> >> Rob Williscroft <r... at freenet.co.uk> wrote:
>> >>>db.execute( '''
>> >>> update "sessions" set "uid" = ?
>> >>> where "uid" = ?
>> >>> and exists(
>> >>> select * from "users" where "uid" > = ?
>> >>> )
>> >>> ''',
>> >>> (v['uid'],s.SID, v['uid'])
>> >>> )
>> >> This will be more efficient if you do "select uid from users".
>> >What will be more efficient ?
>> >Do you mean the "select * ..." or do you want to take the exists
>> >sub-query out and put it in a python if ?
>> "select uid" will be more efficient than "select *", although I
>> suppose I could be wrong about that given how little I know about
>> current query optimizers.
It seems the usual advice about premeture optimisation should apply,
namely write clear code (*), then optimise the bottlenecks when you
actualy find you need to.
*) for some definition of "clear code".
> My take is that it won't matter what you select if the optimiser is
> smart enough; something that requires minimal resources to produce is
> indicated in case the optimiser is dumb:
> ... exists (select 1 from ... )
I have to maintain some code writen by someone who thinks replacing
"*" in queries with "1" is always a good idea (you know just in case),
select count(1) from ...
of course it didn't do what he thought it did.
More information about the Python-list