Hi,
On 2017-09-12 14:28:51 -0400, Robert Haas wrote:
> On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On short-running queries that return a lot of columns,
> >> SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a
> >> noticeable expense.
> >
> > Yeah
On Tue, Sep 12, 2017 at 3:16 PM, Tom Lane wrote:
> I'd say that what you're proposing is the exact opposite of attacking
> the problem at the root.
I agree. But if we're going to install a cache here, on a
cycle-for-cycle basis, it's going to be hard to beat "caching" the
knowledge that OIDs und
Robert Haas writes:
> On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane wrote:
>> The trick here is that I don't think we want to change the returned column
>> types for queries that are not being sent to a client. The parser and
>> planner aren't really aware of that context ATM. Maybe we could make t
On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On short-running queries that return a lot of columns,
>> SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a
>> noticeable expense.
>
> Yeah, I was never very happy with the way that the original domain
> pat
Robert Haas writes:
> On short-running queries that return a lot of columns,
> SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a
> noticeable expense.
Yeah, I was never very happy with the way that the original domain
patch dealt with that. I think you're not even focusing on the
On short-running queries that return a lot of columns,
SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a
noticeable expense. The following change improves performance on a
query returning 100 columns by about 6% when prepared queries are in
use (Mithun Cy and I both tested and got
