On 09/18/2013 06:05 PM, Stephen Frost wrote:
* Kevin Grittner (kgri...@ymail.com) wrote:
Right. Not only would the per-type solution make materialized views
maintenance broken by default, requiring per-type work to make it
work reasonably, with silent failures for any type you didn't know
On 09/18/2013 05:54 PM, Kevin Grittner wrote:
...
I think the hardest part will be documenting the difference between
the row value constructor semantics (which are all that is
currently documented) and the record equality semantics (used for
sorting and building indexes). In a green field I
On 09/18/2013 07:53 PM, Stephen Frost wrote:
I'm really curious about your thoughts on unique indexes then. Should
two numerics which are the same value but different byte
representations be allowed in a unique index?
You could have multiple btree opclasses defined which would enforce
Kevin Grittner kgri...@ymail.com writes:
You are arguing that we should provide lesser support for numeric
columns (and who knows how many other types) in materialized views
than we do in streaming replication, pg_dump,
suppress_redundant_updates_trigger(), and other places? Why?
Because
On 09/19/2013 12:55 AM, Dimitri Fontaine wrote:
We have, as a community, gone to a fair amount of trouble to make
the concept of equality pluggable and allow multiple types of
equality per type. To me it seems the perfect tool to solve this
problem. Why the fuss?
Because I don't
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kgri...@ymail.com writes:
You are arguing that we should provide lesser support for numeric
columns (and who knows how many other types) in materialized views
than we do in streaming replication, pg_dump,
On 09/16/2013 04:01 PM, Kevin Grittner wrote:
Hannu Krosing ha...@2ndquadrant.com wrote:
Lots of people were bitten when (undocumented) hash
functions were changed thus breaking hash-based partitioning.
Nobody can be affected by the new operators in this patch unless
they choose to use them
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote:
I can understand claiming that the risk is acceptable but
arguing it's not there seems extremly strange to me.
It's not a risk. It's why the operator exists.
Pft. It's fine if the materialized
On Tue, Sep 17, 2013 at 8:23 AM, Kevin Grittner kgri...@ymail.com wrote:
Of course, that begs the question of whether == is already taken.
If not, we could knock one '=' off of everything above except for
equals. What existing uses are known for == ?
== is already taken as a common typo in
On 09/17/2013 02:46 PM, Rod Taylor wrote:
On Tue, Sep 17, 2013 at 8:23 AM, Kevin Grittner kgri...@ymail.com
mailto:kgri...@ymail.com wrote:
Of course, that begs the question of whether == is already taken.
If not, we could knock one '=' off of everything above except for
equals.
On 09/17/2013 12:52 AM, Andres Freund wrote:
On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote:
I can understand claiming that the risk is acceptable but arguing
it's not there seems extremly strange to me.
It's not a risk. It's why the operator exists.
Pft. It's fine if the materialized
Kevin Grittner kgri...@ymail.com writes:
= equals (but doesn't necessarily look the same as)
=== IS NOT DISTINCT FROM as an operator
reserved for has no user-visible differences from
= stored image is the same
I understand the need for more than one equality
Hannu Krosing ha...@2ndquadrant.com wrote:
Lots of people were bitten when (undocumented) hash
functions were changed thus breaking hash-based partitioning.
Nobody can be affected by the new operators in this patch unless
they choose to use them to compare two records. They don't work
for any
On 2013-09-15 19:49:26 -0400, Noah Misch wrote:
On Sat, Sep 14, 2013 at 08:58:32PM +0200, Andres Freund wrote:
On 2013-09-14 11:25:52 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
But both arrays don't have the same binary representation since
the former
On Sun, Sep 15, 2013 at 6:49 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Sep 14, 2013 at 08:58:32PM +0200, Andres Freund wrote:
On 2013-09-14 11:25:52 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
But both arrays don't have the same binary representation since
Andres Freund and...@2ndquadrant.com wrote:
I think it's far more realistic to implement an identity operator
that will fall back to a type specific operator iff equals has
strange properties.
My biggest problem with that approach is that it defaults to
incorrect behavior for types for which
On 09/16/2013 04:01 PM, Kevin Grittner wrote:
Hannu Krosing ha...@2ndquadrant.com wrote:
Lots of people were bitten when (undocumented) hash
functions were changed thus breaking hash-based partitioning.
Nobody can be affected by the new operators in this patch unless
they choose to use them
Hannu Krosing ha...@2ndquadrant.com wrote:
What I meant is that rather than leave it really undocumented,
document it as system function for specific usage, has caveats
and may change in future versions. use at your own risk and
make sure you know what you are doing
Well, that was my
On 2013-09-16 10:58:01 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 10:46:53 -0700, Kevin Grittner wrote:
I don't recall seeing anyone posting
regarding the existing undocumented record comparison operators.
Nor do I recall seeing anyone posting
On 2013-09-16 10:46:53 -0700, Kevin Grittner wrote:
One would think so, yet I don't recall seeing anyone posting
regarding the existing undocumented record comparison operators.
Nor do I recall seeing anyone posting about the undocumented
pattern comparison operators.
I've used and have seen
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 10:46:53 -0700, Kevin Grittner wrote:
I don't recall seeing anyone posting
regarding the existing undocumented record comparison operators.
Nor do I recall seeing anyone posting about the undocumented
pattern comparison operators.
On Mon, Sep 16, 2013 at 12:46 PM, Kevin Grittner kgri...@ymail.com wrote:
Hannu Krosing ha...@2ndquadrant.com wrote:
What I meant is that rather than leave it really undocumented,
document it as system function for specific usage, has caveats
and may change in future versions. use at your own
Merlin Moncure mmonc...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
I don't recall seeing anyone posting regarding the existing
undocumented record comparison operators.
This behavior came about via a gripe of mine (but mostly courtesy
Tom Lane_:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 10:58:01 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 10:46:53 -0700, Kevin Grittner wrote:
I don't recall seeing anyone posting regarding the existing
undocumented record comparison operators.
On 2013-09-16 16:58:21 -0400, Noah Misch wrote:
memcmp() has served well for HOT and for _equalConst(); why would it suddenly
fall short for MV maintenance?
I don't have a problem using it internally, I have a problem exposing
the capability to sql. Don't tell me that's the same.
Greetings,
On Mon, Sep 16, 2013 at 04:28:23PM +0200, Andres Freund wrote:
On 2013-09-15 19:49:26 -0400, Noah Misch wrote:
Type-specific identity operators seem like overkill, anyway. If we find
that
meaningless variations in a particular data type are causing too many false
non-matches for the
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 16:58:21 -0400, Noah Misch wrote:
memcmp() has served well for HOT and for _equalConst(); why
would it suddenly fall short for MV maintenance?
I don't have a problem using it internally, I have a problem
exposing the capability to
On 2013-09-16 14:39:30 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 16:58:21 -0400, Noah Misch wrote:
memcmp() has served well for HOT and for _equalConst(); why
would it suddenly fall short for MV maintenance?
I don't have a problem using it
On 2013-09-16 23:58:46 +0200, Andres Freund wrote:
suppress_redundant_updates_trigger() function?
You get superflous trigger calls. So what. It's not usable for anything
but a trigger.
Primarily unneccesary IO, not unneccessary trigger calls (which can also
happen).
Greetings,
Andres
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 14:39:30 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-16 16:58:21 -0400, Noah Misch wrote:
memcmp() has served well for HOT and for _equalConst(); why
would it suddenly fall short for MV
On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote:
I can understand claiming that the risk is acceptable but arguing
it's not there seems extremly strange to me.
It's not a risk. It's why the operator exists.
Pft. It's fine if the materialized view code uses it. I don't see the
danger
Andres Freund and...@2ndquadrant.com wrote:
If matview refreshs weren't using plain SQL and thus wouldn't
require exposing that operator to SQL I wouldn't have a problem
with this...
If RMVC were the end of the story, it might be worth building up a
mass of execution nodes directly, although
On Sat, Sep 14, 2013 at 08:58:32PM +0200, Andres Freund wrote:
On 2013-09-14 11:25:52 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
But both arrays don't have the same binary representation since
the former has a null bitmap, the latter not. So, if you had a
On 09/15/2013 01:35 PM, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
If matview refreshs weren't using plain SQL and thus wouldn't
require exposing that operator to SQL I wouldn't have a problem
with this...
If RMVC were the end of the story, it might be worth building
On 2013-09-13 19:20:11 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Not one that's dependendant on padding bytes, null bitmaps that
can or cannot be present and such.
Can you provide an example of where that's an issue with this
patch?
I haven't yet tested
Andres Freund and...@2ndquadrant.com wrote:
what I am talking about is that
e.g.: SELECT (ARRAY[1,2,3,NULL])[1:3] = ARRAY[1,2,3];
obviously should be true.
The patch does not change the behavior of the = operator for any
type under any circumstances.
But both arrays don't have the same
On 2013-09-14 11:25:52 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
what I am talking about is that
e.g.: SELECT (ARRAY[1,2,3,NULL])[1:3] = ARRAY[1,2,3];
obviously should be true.
The patch does not change the behavior of the = operator for any
type under
On Thu, Sep 12, 2013 at 11:27 PM, Kevin Grittner kgri...@ymail.com wrote:
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
[...]
The patch adds an identical
Benedikt Grundmann bgrundm...@janestreet.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
[...]
The
Hi Kevin,
On 2013-09-12 15:27:27 -0700, Kevin Grittner wrote:
The new operator is logically similar to IS NOT DISTINCT FROM for a
record, although its implementation is very different. For one
thing, it doesn't replace the operation with column level operators
in the parser. For another
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-12 15:27:27 -0700, Kevin Grittner wrote:
The new operator is logically similar to IS NOT DISTINCT FROM for a
record, although its implementation is very different. For one
thing, it doesn't replace the operation with column level
On 2013-09-13 14:36:27 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-12 15:27:27 -0700, Kevin Grittner wrote:
The new operator is logically similar to IS NOT DISTINCT FROM for a
record, although its implementation is very different. For one
thing, it
Andres Freund and...@2ndquadrant.com wrote:
I am not actually that concerned with MVCs using this, you're quite
capable of analyzing the dangers. What I am wary of is exposing an
operator that's basically broken from the get go to SQL.
Now, the obvious issue there is that matviews use SQL to
On 2013-09-13 15:13:20 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
I am not actually that concerned with MVCs using this, you're quite
capable of analyzing the dangers. What I am wary of is exposing an
operator that's basically broken from the get go to SQL.
Andres Freund and...@2ndquadrant.com wrote:
Not one that's dependendant on padding bytes, null bitmaps that
can or cannot be present and such.
Can you provide an example of where that's an issue with this
patch?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
101 - 145 of 145 matches
Mail list logo
