Re: [HACKERS] Re: Performance issue with libpq prepared queries on 9.3 and 9.4 - Mailing list pgsql-general

From Tom Lane
Subject Re: [HACKERS] Re: Performance issue with libpq prepared queries on 9.3 and 9.4
Date
Msg-id 28911.1415928704@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: Performance issue with libpq prepared queries on 9.3 and 9.4  (David Johnston <david.g.johnston@gmail.com>)
List pgsql-general
David Johnston <david.g.johnston@gmail.com> writes:
> ​While "planner hints" comes to mind...on the SQL side can we extend the
> "PREPARE" command with two additional keywords?​

> ​PREPARE
>  name [ ( data_type [, ...] ) ] [
> [NO] GENERIC
> ​] ​
> ​AS statement

Don't really see the point.  The OP's problem is that the prepare is
being driven by a client-side library, which would have even less clue
than the backend as to whether a generic plan is more appropriate than
a custom plan.

The right thing here IMO is to improve the heuristics on the backend
side.  I'm sure we can do better, it's just going to take some thought.

            regards, tom lane


pgsql-general by date:

Previous
From: David Johnston
Date:
Subject: Re: [HACKERS] Re: Performance issue with libpq prepared queries on 9.3 and 9.4
Next
From: Sam Saffron
Date:
Subject: Re: Performance issue with libpq prepared queries on 9.3 and 9.4