launchpad-dev team mailing list archive

[Abel Deuring <abel.deuring@xxxxxxxxxxxxx>]

On 13.08.2010 16:47, Abel Deuring wrote:
> On 12.08.2010 23:35, Robert Collins wrote:
>> Clint, thanks for sharing your experience there - a very close mapping
>> as you say :)
>>
>> Abel, I don't have a particular answer for you just yet - I will read
>> up in more detail.
>>
>> I do have a few constraints that a quick glance at the LEP suggests are missing.
>>
>> Firstly, we need to be able to send the notifications for a changed
>> bug effiicently - I don't mean 'send the mails', I mean 'the time to
>> determine who is subscribed' should be very low.
>>
>> At the moment, I think we take only 2 queries to get the subscribers
>> via direct and structural subscription. We should set a budget - say 1
>> query - to get the subscribers via this new mechanism. This will
>> inform the design :)
>>
>> Secondly, because we can reasonably expect lots of subscriptions, we
>> should require that what comes back from the DB is either precisely
>> the subscribers, or only slightly more: if we bring back 300
>> subscribers and then filtered that down to 150 in python, it would get
>> pretty slow pretty quickly.
> 
> so, that would mean option 1, I think. The question remains if/how we
> can efficiently include a clause "remove all subscriptions for the
> current bug where the full text search filter does not match" in the One
> Big query that returns all subscriptions. But issueing this query for
> each possible subscription from Python would not cause that much more
> load on the DB server, I think. After all, we are not talking about
> rendering a web page but about a script.

It is sometimes a good idea to RTFM early enough... Reading chapter 12
of the Postgresql documentation showed me that we can store tsquery
objects in tables. And we can even create indexes form them. So one or
two queries should be enough to reliably find all subscribers.

Abel