On Wed, Oct 11, 2006 at 02:51:28PM +0530, Kamesh Jayachandran wrote:
> I think you have misunderstood it.
> I have some merges on '/a/b/c' which records the actual mergeinfo which
> is applicable to its child '/a/b/c/d' and grand child '/a/b/c/d/e'...etc.
> When Someone ask for 'mergeinfo' on '/a/b/c/d/e' current
> 'get_merge_info_for_path' gives nothing which my patch fixes it.
>
Is that because we already have a negative cache result for a query
directly on /a/b/c/d? If so, it sounds like we shouldn't be assuming
that a negative cache on /a/b/c/d implies that there's no result on the
parent, or alternatively that we should be caching the parent's value
against /a/b/c/d (though that seems like it would bloat the cache).
I presume that someone has measured that the additional space taken up
by the negative cache entries (and consequently slower lookups) is a net
win over just re-performing the query directly?
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Wed Oct 11 12:34:48 2006