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

From Robert Haas
Subject Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4
Date
Msg-id CA+TgmoagouLzj6bzb-wcQDqO2bsZ=0CRY1jay=vFtbzUbGde9g@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4
List pgsql-hackers
On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> One thing that occurs to me is that if the generic plan estimate comes
> out much cheaper than the custom one, maybe we should assume that the
> generic's cost estimate is bogus.  Right offhand I can't think of a reason
> for a custom plan to look worse than a generic one, unless there's a
> statistical quirk like this one.

That's an interesting idea, but what do we do after deciding that it's
bogus?  The generic plan really can't be cheaper than the custom plan,
but it could be the same price, or as close as makes no difference.

I have long thought that maybe the custom vs. generic plan decision
should have something to do with whether the parameters are MCVs of
the table columns they're being compared against.  This case is
interesting because it demonstrates that querying for a *non*-MCV can
require a switch to a custom plan, which is something I don't think
I've seen before.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: using custom scan nodes to prototype parallel sequential scan
Next
From: Robert Haas
Date:
Subject: Re: group locking: incomplete patch, just for discussion