> 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
>
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
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:
> 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
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.
