| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Re: Performance issue with libpq prepared queries on 9.3 and 9.4 |
| Date: | 2014-11-14 01:31:44 |
| Message-ID: | 28911.1415928704@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
David Johnston <david(dot)g(dot)johnston(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sam Saffron | 2014-11-14 03:31:39 | Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4 |
| Previous Message | David Johnston | 2014-11-14 01:08:35 | Re: Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G Johnston | 2014-11-14 01:35:35 | Re: EXPLAIN ANALYZE output weird for Top-N Sort |
| Previous Message | Peter Eisentraut | 2014-11-14 01:25:21 | Re: Using 128-bit integers for sum, avg and statistics aggregates |