Re: Making the planner more tolerant of implicit/explicit casts - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Making the planner more tolerant of implicit/explicit casts
Date
Msg-id CA+TgmoZiHC6Ln30U3LLZZSdbFsDLdrF3AjJkC=xjiun-86-CwA@mail.gmail.com
Whole thread Raw
In response to Re: Making the planner more tolerant of implicit/explicit casts  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Making the planner more tolerant of implicit/explicit casts  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 11, 2012 at 5:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm reasonably convinced that this is a good fix for HEAD, but am of two
> minds whether to back-patch it or not.  The problem complained of in
> bug #7598 may seem a bit narrow, but the real point is that whether you
> write a cast explicitly or not shouldn't affect planning if the
> semantics are the same.  This might well be a significant though
> previously unrecognized performance issue, particularly for people who
> use varchar columns heavily.

I have had a few bad experiences with people getting *really* upset
about plan changes in minor releases, so I would be disinclined to
back-patch this, even if we're fairly sure that it will be an
improvement in most/all cases.  It's just not worth the risk of
discovering otherwise.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: smgrsettransient mechanism is full of bugs
Next
From: Robert Haas
Date:
Subject: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)