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 n...@leadboat.com wrote:
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
I think for any pair of types (T1,
On Wed, Jan 5, 2011 at 11:26 PM, Noah Misch n...@leadboat.com 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 n...@leadboat.com wrote:
On Wed, Dec 29, 2010 at
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 the
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 a
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com 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
On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch n...@leadboat.com 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
On Fri, Dec 31, 2010 at 12:34:50AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch n...@leadboat.com 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
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
On Dec 29, 2010, at 7:56 AM, Noah Misch n...@leadboat.com 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
Noah Misch n...@leadboat.com 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
Robert Haas robertmh...@gmail.com writes:
On Dec 29, 2010, at 7:56 AM, Noah Misch n...@leadboat.com 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,
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
On Dec 29, 2010, at 11:16 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Dec 29, 2010, at 11:16 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Dec 29, 2010 at 10:56:39AM -0500, Robert Haas wrote:
On Dec 29, 2010, at 7:56 AM, Noah Misch n...@leadboat.com 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
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
On Wed, Dec 29, 2010 at 02:01:28PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Dec 29, 2010, at 11:16 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch n...@leadboat.com 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
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch n...@leadboat.com 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
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com 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 n...@leadboat.com wrote:
Perhaps. ?A few kooky rows is indeed common, but we're talking about a
specific
breed of
20 matches
Mail list logo
