Re: Prepared statements and generic plans

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "''bruce(at)momjian(dot)us' *EXTERN*'" <bruce(at)momjian(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Prepared statements and generic plans
Date: 2016-06-14 08:37:12
Message-ID: A737B7A37273E048B164557ADEF4A58B53860777@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
> However, for the wire protocol prepare/execute, how do you do EXPLAIN?
> The only way I can see doing it is to put the EXPLAIN in the prepare
> query, but I wasn't sure that works. So, I just wrote and tested the
> attached C program and it properly output the explain information, e.g.
>
> res = PQprepare(conn, "prep1", "EXPLAIN SELECT * FROM pg_language", 0, NULL);
> -------
> generated:
>
> QUERY PLAN
>
> Seq Scan on pg_language (cost=0.00..1.04 rows=4 width=114)
>
> so that works --- good.

Hm, yes.

Were you just curious or is it relevant for the documentation update?

>>> Looking at how the code behaves, it seems custom plans that are _more_
>>> expensive (plus planning cost) than the generic plan switch to the
>>> generic plan after five executions, as now documented. Custom plans
>>> that are significantly _cheaper_ than the generic plan _never_ use the
>>> generic plan.
>>
>> Yes, that's what the suggested documentation improvement says as well,
>> right?
>
> Yes. What is odd is that it isn't the plan of the actual supplied
> parameters that is cheaper, just the generic plan that assumes each
> distinct value in the query is equally likely to be used. So, when we
> say the generic plan is cheaper, it is just comparing the custom plan
> with the supplied parameters vs. the generic plan --- it is not saying
> that running the supplied constants with the generic plan will execute
> faster, because in fact we might be using a sub-optimial generic plan.

Right, that's why it is important to document that it is estimates that are
compared, not actual costs.

This has caused confussion in the past, see
https://www.postgresql.org/message-id/flat/561E749D(dot)4090301%40socialserve(dot)com#561E749D(dot)4090301(at)socialserve(dot)com

> Right. Updated patch attached.

I am happy with the patch as it is.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2016-06-14 10:01:57 Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Previous Message Amit Langote 2016-06-14 08:06:53 Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116