On Wed, Sep 22, 2010 at 11:25 PM, Greg Stein <gst...@gmail.com> wrote:
> On Wed, Sep 22, 2010 at 05:39, <phi...@apache.org> wrote: > >... > > +++ subversion/trunk/subversion/libsvn_wc/wc-queries.sql Wed Sep 22 > 09:39:45 2010 > > @@ -215,7 +215,7 @@ update nodes set properties = ?3 > > where wc_id = ?1 and local_relpath = ?2 > > and op_depth in > > (select op_depth from nodes > > - where wc_id = ?1 and local_relpath = ?2 > > + where wc_id = ?1 and local_relpath = ?2 and op_depth > 0 > > order by op_depth desc > > limit 1); > > Wouldn't it be better to do: > > where wc_id = ?1 and local_relpath = ?2 > and op_depth = (select max(op_depth) from nodes > where wc_id=?1 and local_relpath=?2 and op_depth > 0); > > It seems that eliminating the "order by" and "limit", in favor of > max() will tell sqlite what we're really searching for: the maximal > value. > > I wrote those queries like that because Bert said it would introduce an aggregation function - at the time he said it, that sounded like it was something negative. > Also note that the above query uses "op_depth in (...)" > > yet: > > > > > @@ -312,7 +312,7 @@ WHERE wc_id = ?1 AND local_relpath = ?2; > > update nodes set translated_size = ?3, last_mod_time = ?4 > > where wc_id = ?1 and local_relpath = ?2 > > and op_depth = (select op_depth from nodes > > - where wc_id = ?1 and local_relpath = ?2 > > + where wc_id = ?1 and local_relpath = ?2 and op_depth > > 0 > > order by op_depth desc > > limit 1); > > This one does not. The rest of the statements you converted all use > the "in" variant. > The "in" variant is probably better, because - especially with the op_depth > 0 restriction - the result set can probably be empty. Bye, Erik.
