Re: Strange sort node/explain result - Mailing list pgsql-bugs

From David Rowley
Subject Re: Strange sort node/explain result
Date
Msg-id CAApHDvpTrP48-=+gdnxryuZVENB9jvoEVsXNjbJ5aBnQoa=TrQ@mail.gmail.com
Whole thread Raw
In response to Re: Strange sort node/explain result  ("Gunnar \"Nick\" Bluth" <gunnar.bluth@pro-open.de>)
List pgsql-bugs
On Wed, 2 Nov 2022 at 02:13, Gunnar "Nick" Bluth
<gunnar.bluth@pro-open.de> wrote:
> So the sort could also say
>     "rows=366 loops=26926"
> instead of
>     "rows=9855001 loops=1"
>
> (which I myself would find reasonable...)?

Maybe my example led you to believe that we rewind (rescan) the inner
node each time we finish matching an outer tuple, but that's not what
happens. We only restore back to the marked position, after we've just
fetched the next outer tuple and see that the new outer matches the
tuple that we've marked on the inner side.

The maths just wouldn't make any sense if we incremented the loop
counter each time we did a restore.  When we call ExecRestrPos we
could either jump back 0 rows, or jump back to the very start of the
scan. It just depends on the marked position. I think you're under the
impression that if you multiply rows by loops that you'd get a number
that would actually make sense here. It wouldn't.

David



pgsql-bugs by date:

Previous
From: "Gunnar \"Nick\" Bluth"
Date:
Subject: Re: Strange sort node/explain result
Next
From: PG Bug reporting form
Date:
Subject: BUG #17674: undefined symbol: pg_fprintf