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
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
19 matches
Mail list logo
