Hello,
I'm facing a strange behaviour and I don't understand why. From a wider query
plan, https://explain.dalibo.com/plan/7yh ,a table is scanned and filter based
on its primary key, returning 98 records. Then, those records are sorted on
another field, and the output is 758,247,643 records.
Nicolas Seinlet writes:
> I'm facing a strange behaviour and I don't understand why. From a wider query
> plan, https://explain.dalibo.com/plan/7yh ,a table is scanned and filter
> based on its primary key, returning 98 records. Then, those records are
> sorted on another field, and the output
On Tuesday, July 20th, 2021 at 16:34, Tom Lane wrote:
> Nicolas Seinlet nico...@seinlet.com writes:
>
> > I'm facing a strange behaviour and I don't understand why. From a wider
> > query plan, https://explain.dalibo.com/plan/7yh ,a table is scanned and
> > filter based on its primary key, re
Nicolas Seinlet writes:
> Many thanks for the fast response. The full query plan is below, and the
> Dalibo link points to it as well. You're right, it's a merge join. One table
> doesn't have up-to-date statistics, because the table is filled during the
> transaction involving this query.
Sur
> Query:
> INSERT INTO invl_aml_mapping_temp(invl_id, aml_id, cond)
>SELECT il.id, ml.id, 48
>FROM account_invoice_line il
>JOIN account_invoice i ON i.id = il.invoice_id
>JOIN account_move m ON m.id = i.move_id
>
