[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Antw: Re: mdb index reporting available?
>>> Michael Ströder <michael@stroeder.com> schrieb am 19.08.2019 um 10:44 in
Nachricht <27f4384a-5d12-c6b3-3e1d-f85400e2a84a@stroeder.com>:
> On 8/19/19 9:24 AM, Ulrich Windl wrote:
>>>>> Michael Ströder <michael@stroeder.com> schrieb am 17.08.2019 um 20:37
in
>> Nachricht <123c2421-b539-14cb-6c82-44235675b5cd@stroeder.com>:
>>> On 8/17/19 2:52 PM, Marc Roos wrote:
>>>> Over time I am adding indexes until there are no such messages
>>>> (except for some incidental queries).
>>> And that's exactly the wrong thing to do!
>>> That's why I requested to disable those messages in ITS#7796:
>>>
>>> https://www.openldap.org/its/index.cgi?findid=7796
>>>
>>> By adding random indexes just to get rid of not-indexed warnings you can
>>> dramatically lower your search performance. You should only add an index
>>> if you analyzed that clients send search requests with filters which can
>>> make good use of the index.
>>
>> I agree that some thinking before adding an index isn't a bad idea, but
> still
>> I think these messages are important as they can make you start thinking.
>
> Experience shows that people do not analyse the LDAP filters but just
> add an index to get rid of the message. You can find that many times in
> various discussion / Q&A forums.
>
> It's also bad that this message is written at any loglevel. Depending on
> your config it can be written many times for the same attribute during
> processing a single search operation, e.g. when processing the numerous
> set-based ACLs in my Æ-DIR. 50+ senseless log lines for a single search
> operation with deref control is not fun.
I could imagine that either...
* writing each message only once since slapd started
* suppressing each message for a configurable time interval (like 1 hour, 1
day, 1 week, etc.)
... would be a solution people could live with.
As for the case: Can you present an example here where an index added as
suggested makes performance actually worse?
>
> Ciao, Michael.