У пон, 04. 05 2009. у 11:25 +0000, Jeroen T. Vermeulen пише:
>
> * When checking "msgid_{singular,plural} IN (...)," don't check for
> "msgid_{singular,plural} IS NOT NULL" as well. (One seq scan on
> POTMsgSet happens there).
We can probably avoid seqscans just with clause reordering. That's what
usually helped.
> * The POMsgID seq scan for matches is slow. For plurals, the plan
> first limits the search to ones belonging to relevant POTMsgSets which
> makes it much faster. See if we can get the same in the plan for
> singulars, or if we can't, either materialize into a temp table or
> replace the union of the msgid_singular and msgid_plural subqueries
> with a single query (using either OR or a double LEFT JOIN).
Actually, it used to be a LEFT JOIN, but UNION performed much better on
staging during initial testing, which is why I rewrote the query as a
UNION.
Considering we are seeing only a few of these, I wouldn't consider this
very important unless we get >10 timeouts a day.
У пон, 04. 05 2009. у 11:25 +0000, Jeroen T. Vermeulen пише: {singular, plural} IN (...)," don't check for {singular, plural} IS NOT NULL" as well. (One seq scan on
>
> * When checking "msgid_
> "msgid_
> POTMsgSet happens there).
We can probably avoid seqscans just with clause reordering. That's what
usually helped.
> * The POMsgID seq scan for matches is slow. For plurals, the plan
> first limits the search to ones belonging to relevant POTMsgSets which
> makes it much faster. See if we can get the same in the plan for
> singulars, or if we can't, either materialize into a temp table or
> replace the union of the msgid_singular and msgid_plural subqueries
> with a single query (using either OR or a double LEFT JOIN).
Actually, it used to be a LEFT JOIN, but UNION performed much better on
staging during initial testing, which is why I rewrote the query as a
UNION.
Considering we are seeing only a few of these, I wouldn't consider this
very important unless we get >10 timeouts a day.