Lieferplan: längere Antwortzeiten mit steigendem Datenbestand

[od-peter]

Bei einer etwas größeren Installation haben wir leider das Problem, das mit steigender Anzahl an Aufträgen/Lieferscheinen? die Performance des Lieferplans zunehmend schlechter wird.

Aktuell liegt die Antwortzeit bei knapp 2 Minuten (!), so dass der Lieferplan praktisch unbenutzbar ist.
Der Report liefert dabei 68 Seiten (mit je 40 Positionen pro Seite) Auch jeder weitere Änderung im fertigen Report (Änderung der Sortierung, anwenden von Filtern) oder der CSV/PDF-Export dauert min. genau so lange...

Uff da brauch ich viel mehr Informationen. Oder Ihr nehmt das Query selbst auseinander und schaut warum das so langsam ist.

Merge Join (cost=0.00..222230.20 rows=368 width=4)

Merge Cond: (rl.from_id = oi.trans_id)
Join Filter: (NOT (SubPlan? 1))
-> Merge Join (cost=0.00..1691.00 rows=158 width=12)

Merge Cond: (oe.id = rl.from_id)
-> Index Scan using oe_pkey on oe (cost=0.00..1124.00 rows=389 width=4)

Filter: ((customer_id IS NOT NULL) AND ((NOT quotation) OR (quotation IS NULL)) AND (NOT closed))

-> Index Scan using idx_record_links_from_id on record_links rl (cost=0.00..599.44 rows=4508 width=8)

Filter: (((from_table)::text = 'oe'::text) AND ((to_table)::text = 'delivery_orders'::text))

-> Index Scan using orderitems_trans_id_key on orderitems oi (cost=0.00..2729.84 rows=27631 width=12)
SubPlan? 1

-> Seq Scan on delivery_order_items doi (cost=0.00..974.81 rows=3 width=4)

Filter: (delivery_order_id = rl.to_id)

(13 rows)

Im Livesystem debuggt, Schritt 5 im Query hängt lange (siehe query planer oben)

Ok, hab nen besseren Algorithmus, und dabei auch noch bugs im aktuellen algorithmus entdeckt, die aufteten, wenn jemand 2 Lieferscheine für einen Auftrag anlegt, und nur in einem von beiden bestimte Waren besetzt.

nicht finales query:

SELECT incmap.id from (

SELECT oi.id, oi.trans_id, agg.parts_id, rl.to_id
FROM orderitems oi LEFT JOIN (

SELECT rl.from_id as oid, doi.parts_id, count(doi.id) FROM (

SELECT from_id, to_id
FROM record_links rl
LEFT JOIN oe ON oe.id = from_id
WHERE

rl.from_table = 'oe' AND
rl.to_table = 'delivery_orders' AND

oe.customer_id IS NOT NULL AND
(oe.quotation = 'f' OR oe.quotation IS NULL) AND NOT oe.closed

) rl
LEFT JOIN delivery_order_items doi ON (rl.to_id = doi.delivery_order_id)
GROUP BY rl.from_id, rl.to_id, doi.parts_id

) agg ON agg.oid = oi.trans_id AND
agg.parts_id = oi.parts_id
LEFT JOIN record_links rl ON oi.trans_id = rl.from_id AND rl.from_table = 'oe'

) incmap
LEFT JOIN oe ON oe.id = incmap.trans_id
WHERE parts_id IS NULL AND incmap.to_id > 0 AND
oe.customer_id IS NOT NULL AND

(oe.quotation = 'f' OR oe.quotation IS NULL) AND NOT oe.closed

Ich lasse den Bug mal offen für späteres testen.

Neue Version, die einige bugs noch behebt:

SELECT oi.id

FROM orderitems oi LEFT JOIN (

SELECT rl.from_id as oid, doi.parts_id, sum(doi.qty) FROM (

SELECT from_id, to_id
FROM record_links rl
LEFT JOIN oe ON oe.id = from_id
WHERE

rl.from_table = 'oe' AND
rl.to_table = 'delivery_orders' AND

oe.customer_id IS NOT NULL AND
(oe.quotation = 'f' OR oe.quotation IS NULL) AND NOT oe.closed

) rl
LEFT JOIN delivery_order_items doi ON (rl.to_id = doi.delivery_order_id)
GROUP BY rl.from_id, doi.parts_id

) agg ON (agg.oid = oi.trans_id AND agg.parts_id = oi.parts_id)
LEFT JOIN oe ON oe.id = oi.trans_id
WHERE

EXISTS (

SELECT to_id
FROM record_links rl
WHERE oi.trans_id = rl.from_id AND rl.from_table = 'oe' AND rl.to_table = 'delivery_orders'

) AND
coalesce(sum, 0) < oi.qty AND
oe.customer_id IS NOT NULL AND
(oe.quotation = 'f' OR oe.quotation IS NULL) AND NOT oe.closed

letzte version live, in cetaq und von peter getestet. committe das

schliesse den bug erstmal, wenn was ist, bitte hier wieder öffnen.