On Thu, Oct 3, 2013 at 10:46:05AM -0700, Kevin Grittner wrote:
opcname
-
varchar_ops
kd_point_ops
cidr_ops
text_pattern_ops
varchar_pattern_ops
bpchar_pattern_ops
(6 rows)
Do these all have operators defined too?
On 09/30/2013 09:08 AM, Kevin Grittner wrote:
Steve Singer st...@ssinger.info wrote:
How about
To support matching of rows which include elements without a default
B-tree operator class, the following operators are defined for composite
type comparison:
literal*=/,
On Thu, Oct 3, 2013 at 09:59:03AM -0400, Steve Singer wrote:
Are there any outstanding issues on this patch preventing it from
being committed?
I have not received answers to my email of October 1:
http://www.postgresql.org/message-id/20131001024620.gb13...@momjian.us
--
Bruce
Steve,
Thanks for following-up on this; I had meant to reply much sooner but
other things got in the way.
Thanks again,
Stephen
* Steve Singer (st...@ssinger.info) wrote:
Are there any outstanding issues on this patch preventing it from
being committed?
I think we
Bruce Momjian br...@momjian.us wrote:
On Fri, Sep 27, 2013 at 03:34:20PM -0700, Kevin Grittner wrote:
We first need to document the existing record comparison operators.
If they read the docs for comparing row_constructors and expect
that to be the behavior they get when they compare records,
Steve Singer st...@ssinger.info wrote:
You haven't adjusted the patch to reduce the duplication between the
equality and comparison functions, if you disagree with me and feel that
doing so would increase the code complexity and be inconsistent with how
we do things elsewhere that is fine.
I
Steve Singer st...@ssinger.info wrote:
How about
To support matching of rows which include elements without a default
B-tree operator class, the following operators are defined for composite
type comparison:
literal*=/,
literal*lt;gt;/,
literal*lt;/,
On Fri, Sep 27, 2013 at 03:34:20PM -0700, Kevin Grittner wrote:
The arguments for this patch are
* We want the materialized view to return the same value as
would be returned if the query were executed directly. This not
only means that the values should be the same according to a
On 09/28/2013 03:03 PM, Kevin Grittner wrote:
para
+To support matching of rows which include elements without a default
+B-tree operator class, the following operators are defined for composite
+type comparison:
+literal*=/,
+literal*lt;gt;/,
+literal*lt;/,
+
Kevin Grittner kgri...@ymail.com wrote:
Bruce Momjian br...@momjian.us wrote:
I think we need to see a patch from Kevin that shows all the row
comparisons documented and we can see the impact of the
user-visibile part.
First draft attached.
I'm inclined to first submit a proposed
Bruce Momjian br...@momjian.us wrote:
On Thu, Sep 19, 2013 at 06:31:38PM -0400, Steve Singer wrote:
On 09/12/2013 06:27 PM, Kevin Grittner 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
On Thu, Sep 19, 2013 at 06:31:38PM -0400, Steve Singer wrote:
On 09/12/2013 06:27 PM, Kevin Grittner 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.
On Thu, Sep 26, 2013 at 05:50:08PM -0400, Bruce Momjian wrote:
I think we need to see a patch from Kevin that shows all the row
comparisons documented and we can see the impact of the user-visibile
part.
One interesting approach would be to only allow the operator to be
called from SPI
On Thu, Sep 19, 2013 at 06:31:38PM -0400, Steve Singer wrote:
I think there is agreement that better (as in more obscure)
operators than === and !== need to be picked and we need to find a
place in the user-docs to warn users of the behaviour of this
operators. Hannu has proposed
*==*
Steve Singer st...@ssinger.info wrote:
On 09/12/2013 06:27 PM, Kevin Grittner 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.
Here is attempt at a
Steve,
Thanks for providing a summary.
* Steve Singer (st...@ssinger.info) wrote:
The arguments for this patch are
* We want the materialized view to return the same value as would be
returned if the query were executed directly. This not only means
that the values should be the same
Stephen Frost sfr...@snowman.net wrote:
The issue here is that we're trying to make the mat view look
like what the query would do when run at the same time, which is
a bit of a losing battle, imv.
If we're not doing that, I don't see the point of matviews.
--
Kevin Grittner
EDB:
On Friday, September 20, 2013, Kevin Grittner wrote:
Stephen Frost sfr...@snowman.net javascript:; wrote:
The issue here is that we're trying to make the mat view look
like what the query would do when run at the same time, which is
a bit of a losing battle, imv.
If we're not doing
Stephen Frost sfr...@snowman.net wrote:
On Friday, September 20, 2013, Kevin Grittner wrote:
Stephen Frost sfr...@snowman.net wrote:
The issue here is that we're trying to make the mat view look
like what the query would do when run at the same time, which
is a bit of a losing battle, imv.
On 09/20/2013 08:38 AM, Kevin Grittner wrote:
Did you look at the record_eq and record_cmp functions which exist
before this patch? Is there a reason we should do it one way for the
default operators and another way for this alternative?
Do you think we should change record_eq and record_cmp
On 09/12/2013 06:27 PM, Kevin Grittner 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.
Here is attempt at a review of the v1 patch.
There has been a
21 matches
Mail list logo
