Greg Stein <[email protected]> writes:
> To do this, it seems that we're going to need to expose (from wc_db.h)
> a structure containing "all" the row data. Thankfully, this big ol'
> structure is *private* to libsvn_wc, and we can change it at will
> (unlike svn_wc_status_t). I would suggest that we use a callback --
> wc_db can step through each row of the result, fill in the structure,
> and execute a callback (clearing an iterpool on each "step" with the
> cursor).
Yes, the caching is private to libsvn_wc. It might even be private to
status within libsvn_wc initially.
> The one tricky part to a callback is eliding all but the highest
> op_depth. Does an ORDER BY in the query affect its runtime at all?
I had the following indices on NODES:
PRIMARY KEY(wc_id, local_relpath, op_depth)
CREATE INDEX i_parent ON NODES (wc_id, parent_relpath, local_relpath)
if I change the i_parent index to
CREATE INDEX i_parent ON NODES (wc_id, parent_relpath, local_relpath, op_depth)
then the order by on this query
SELECT ... FROM NODES
WHERE wc_id = ?1 AND parent_relpath = ?2
ORDER BY local_relpath, op_depth
doesn't add a significant overhead.
--
Philip
