Re: Consequence of changes to CTE's in 12

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com>
Cc: Michael Lewis <mlewis(at)entrata(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Consequence of changes to CTE's in 12
Date: 2021-02-12 00:45:30
Message-ID: 1511206.1613090730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> writes:
> Is there a chance that the query optimiser should 'notice' the
> pg_try_advisory_xact_lock function, and not be so clever when it sees it?

The general policy with respect to volatile functions in WHERE quals is
"here be dragons". You don't have enough control over when a WHERE clause
will be evaluated to be sure about what the semantics will be; and we
don't want to tie the optimizer's hands to the extent that would be needed
to make it fully predictable.

In this particular case, you can make it fairly safe by making sure there
are optimization fences both above and below where the WHERE clause is.
You have one above from the LIMIT 1, but (with the new interpretation of
CTEs) not one below it. Adding a fence -- either OFFSET 0 or LIMIT ALL --
to the first CTE should fix it in a reasonably version-independent
fashion.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Baldwin 2021-02-12 00:54:37 Re: Consequence of changes to CTE's in 12
Previous Message Steve Baldwin 2021-02-12 00:36:52 Re: Consequence of changes to CTE's in 12