Re: SET or STRICT modifiers on function affect planner row estimates

From: Michał Kłeczek <michal(at)kleczek(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SET or STRICT modifiers on function affect planner row estimates
Date: 2024-10-01 12:30:04
Message-ID: 7F201138-001D-4DFD-A4AD-82717D0F160D@kleczek.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

> On 30 Sep 2024, at 21:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <michal(at)kleczek(dot)org> writes:
>>>
>
>> The table structure is as follows:
>
>> CREATE TABLE tbl (…) PARTITION BY RANGE year(col02_date)
>
> You're still expecting people to magically intuit what all those
> "..."s are. I could spend many minutes trying to reconstruct
> a runnable example from these fragments, and if it didn't behave
> as you say, it'd be wasted effort because I didn't guess right
> about some un-mentioned detail. Please provide a *self-contained*
> example if you want someone to poke into this in any detail.

Indeed - didn’t have time to provide a fully executable reproducer.
The issues are in a restricted environment and I cannot share any details.
Will try to provide one though.

OTOH the table structure itself didn’t seem important to me in this case
since the planner works fine in the first case. Anyway - the structure is:

CREATE TABLE tbl (col01_no text NOT NULL, col02_date date, col03 double precision)
PARTITION BY RANGE year(col02_date);

The functions year(date) and month(date) are shared in an extension common to all servers.

> You have not mentioned your PG version, either.

Indeed:
16.1

>
> My first guess would be that adding STRICT or adding a SET clause
> prevents function inlining, because it does. However, your Plan 2
> doesn't seem to involve a FunctionScan node, so either these plans
> aren't really what you say or there's something else going on.

Maybe this wasn’t stated clearly enough that the second plan was reported by auto_analyze in the logs.

That the function is not inlined is clear from the docs.
But what is not clear is why the query is planned differently in non-inlined functions.

The outer query is:

SELECT * FROM report(‘col01value’, 2021, 1, 2023, 12);

Kind regards


Michal

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2024-10-01 12:43:20 Re: Truncate logs by max_log_size
Previous Message Amit Kapila 2024-10-01 12:15:47 Re: Using per-transaction memory contexts for storing decoded tuples