On Thu, Jan 06, 2011 at 12:24:19AM -0500, Robert Haas wrote:
> I still think you're better off focusing first on the case where we
> can skip the whole nine yards, and doing this stuff as a follow-on
> patch. Trying to do too many things, especially possibly
> controversial stuff, especially in th
On Wed, Jan 5, 2011 at 11:26 PM, Noah Misch wrote:
> On Thu, Dec 30, 2010 at 08:35:34PM -0500, Noah Misch wrote:
>> On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
>> > On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
>> > > On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wr
On Thu, Dec 30, 2010 at 08:35:34PM -0500, Noah Misch wrote:
> On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
> > On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
> > > On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
> > >> I think for any pair of types (T1, T2) we sho
On Fri, Dec 31, 2010 at 12:34:50AM -0500, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch wrote:
> > 4. A FuncExpr node has answers given by the bitwise-AND of its funcexempt
> > field
> > and the answers from its first argument.
>
> Why its first argument?
funcexempt would onl
On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch wrote:
> 4. A FuncExpr node has answers given by the bitwise-AND of its funcexempt
> field
> and the answers from its first argument.
Why its first argument?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
> > On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
> >> I think for any pair of types (T1, T2) we should first determine
> >> whether we can skip the scan altogether. ?I
On Dec 29, 2010, at 10:14 PM, Robert Haas wrote:
> +1 for trying to optimize these cases (but maybe after we optimize the
> varchar -> text and varchar(less) -> varchar(more) cases to skip the
> scan altogether).
+1 on getting the obvious cases of varchar and numeric done first; we run into
those
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
> On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
>> On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch wrote:
>> > Perhaps. ?A few kooky rows is indeed common, but we're talking about a
>> > specific
>> > breed of kookiness: 99.9% of the
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
> On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch wrote:
> > Perhaps. ?A few kooky rows is indeed common, but we're talking about a
> > specific
> > breed of kookiness: 99.9% of the rows have identical bits after an ALTER
> > TYPE
> > tran
On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch wrote:
>> I think this scenario will be more common than you might think. Tables
>> don't contain random data; they contain data that the DBA thinks is valid.
>> The situation where the data is mostly as you expect but with a few kooky
>> rows is, i
On Wed, Dec 29, 2010 at 02:01:28PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Dec 29, 2010, at 11:16 AM, Tom Lane wrote:
> >> I really really dislike the notion of a "verification scan": it's
> >> basically work that is going to be useless if it fails.
>
> > I think it has potential in
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> > some
> > cases, we can determine that doing so is unhelpful, and that the conversion
> > shall always succeed:
> > I wish to replace ta
On Wed, Dec 29, 2010 at 10:56:39AM -0500, Robert Haas wrote:
> On Dec 29, 2010, at 7:56 AM, Noah Misch wrote:
> > Having thought on it
> > more, though, it actually seems best to attempt the verification scan
> > *every*
> > time. In most ineligible conversions, an inequality will appear very
>
Robert Haas writes:
> On Dec 29, 2010, at 11:16 AM, Tom Lane wrote:
>> I really really dislike the notion of a "verification scan": it's
>> basically work that is going to be useless if it fails.
> I think it has potential in cases like text to xml. In that case it'll
> either work or fail, wi
On Dec 29, 2010, at 11:16 AM, Tom Lane wrote:
> I really really dislike the notion of a "verification scan": it's
> basically work that is going to be useless if it fails.
I think it has potential in cases like text to xml. In that case it'll either
work or fail, with no possibility of requirin
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> > some
> > cases, we can determine that doing so is unhelpful, and that the conversion
> > shall always succeed:
> > I wish to replace ta
Robert Haas writes:
> On Dec 29, 2010, at 7:56 AM, Noah Misch wrote:
>> The exemptor shall have this signature:
>>
>> exemptor_func(
>> integer, -- source_typmod
>> integer -- dest_typmod
>> ) RETURNS boolean
>>
>> The exemptor shall return true iff datumIsEqual(x,
>> x::target_type(dest_typm
Noah Misch writes:
> ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> some
> cases, we can determine that doing so is unhelpful, and that the conversion
> shall always succeed:
> I wish to replace table rewrites with table verification scans where possible,
> then skip
On Dec 29, 2010, at 7:56 AM, Noah Misch wrote:
> ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
> some
> cases, we can determine that doing so is unhelpful, and that the conversion
> shall always succeed:
>
> CREATE DOMAIN loosedom AS text;
> CREATE TABLE t (c varchar
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
CREATE DOMAIN loosedom AS text;
CREATE TABLE t (c varchar(2));
ALTER TABLE t ALTER c TYPE varchar(4);
ALTER TABLE t ALTE
20 matches
Mail list logo
