one does have thoughts on what could be
happening I would be very interested to hear, but the main performance
problem is effectively solved.
Thanks all for the valuable help getting to the bottom of what was
happening.
On Tue, 5 May 2020 at 22:42, Tom Lane wrote:
> James Thompson writes:
>
I've managed to replicate this now with prepared statements. Thanks for all
the guidance so far.
The slowness occurs when the prepared statement changes to a generic plan.
Initial plan:
-> Index Only Scan using table1_typea_include_uniqueid_col16_idx on table1
table1alias2 (cost=0.56..2549.70 r
/ heap fetches seems unlikely to be
causing this? Any other thoughts?
Thanks!
On Sun, 3 May 2020 at 16:38, Justin Pryzby wrote:
> On Sun, May 03, 2020 at 09:58:27AM +0100, James Thompson wrote:
> > Hi,
> >
> > Hoping someone can help with this performance issue that's b
Hi,
Hoping someone can help with this performance issue that's been driving a
few of us crazy :-) Any guidance greatly appreciated.
A description of what you are trying to achieve and what results you
expect.:
- I'd like to get an understanding of why the following query (presented
in full, but
