Dieter Maurer wrote:
But overall, unless you have special (non DC derived) indexes,
That can well be the case...
Anyway, what are we going to do about this crawling tab?
Chris
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/l
Chris Withers wrote at 2003-7-21 08:22 +0100:
> Dieter Maurer wrote:
> > "#objects" suggests that it is the number of objects indexed by
> > this index. Who is interested in this information?
>
> Well, it's been useful to be on several occasions when I've seen one index has
> less objects i
Dieter Maurer wrote:
"#objects" suggests that it is the number of objects indexed by
this index. Who is interested in this information?
Well, it's been useful to be on several occasions when I've seen one index has
less objects in than another...
Unless one has inhomogeous objects, almost all obj
Anthony Baxter wrote at 2003-7-18 15:14 +1000:
>
> >>> Andreas Jung wrote
> > I agree but the current implementation sux. Switching to a counter based
> > solution would solve the problem. The only problem I see is to keep the
> > code fully backward compatible.
>
> if there's no counter p
On Friday 18 July 2003 01:29 pm, Dieter Maurer wrote:
> Anthony Baxter wrote at 2003-7-18 15:14 +1000:
> >
> > >>> Andreas Jung wrote
> > > I agree but the current implementation sux. Switching to a counter
based
> > > solution would solve the problem. The only problem I see is to keep the
>
--On Freitag, 18. Juli 2003 13:53 Uhr +0100 Chris Withers
<[EMAIL PROTECTED]> wrote:
Anthony Baxter wrote:
if there's no counter present:
create one, do a count of the docs, initialise the counter
display counter
Sounds good, what needs to happen to make this happen?
Since this is a bug fix
--On Freitag, 18. Juli 2003 13:52 Uhr +0100 Chris Withers
<[EMAIL PROTECTED]> wrote:
Dieter Maurer wrote:
I suggest to change the title to "# index terms" and
revert for the indexes to the old behaviour.
If that'll make it quicker, cool :-)
I am usually not interested in the number of index ter
Anthony Baxter wrote:
if there's no counter present:
create one, do a count of the docs, initialise the counter
display counter
Sounds good, what needs to happen to make this happen?
Since this is a bug fix, can it go on the 2.6 branch?
cheers,
Chris
_
Dieter Maurer wrote:
I suggest to change the title to "# index terms" and
revert for the indexes to the old behaviour.
If that'll make it quicker, cool :-)
Others pointed out, that also the size determination for an
index may be expensive. However, it is at most linear in the number
(rather than q
Casey Duncan wrote:
Actually I regard the current behavior as a feature. Using a stopwatch and a
slide-rule I can estimate to within 100 objects, how many values are indexed
in a catalog by measuring the time it takes to draw the indexes page.
Please do not remove this most valued feature!
I see
>>> Andreas Jung wrote
> I agree but the current implementation sux. Switching to a counter based
> solution would solve the problem. The only problem I see is to keep the
> code fully backward compatible.
if there's no counter present:
create one, do a count of the docs, initialise the counte
--On Donnerstag, 17. Juli 2003 18:22 Uhr -0400 Casey Duncan
<[EMAIL PROTECTED]> wrote:
Actually I regard the current behavior as a feature. Using a stopwatch
and a slide-rule I can estimate to within 100 objects, how many values
are indexed in a catalog by measuring the time it takes to draw
Actually I regard the current behavior as a feature. Using a stopwatch and a
slide-rule I can estimate to within 100 objects, how many values are indexed
in a catalog by measuring the time it takes to draw the indexes page.
Please do not remove this most valued feature!
-Casey
On Thursday 17 J
Chris Withers wrote at 2003-7-17 11:12 +0100:
> Has anyone noticed that the ZCatalog Indexes tab crawls if you have loads of
> objects indexed.
>
> My guess is that some types of index take way too long to figure out how many
> objects are indexed. Anyone know which index types those could
14 matches
Mail list logo
