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 op
Steve Singer 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 think the main
Bruce Momjian 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, they
>>
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
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 Mo
On 09/30/2013 09:08 AM, Kevin Grittner wrote:
Steve Singer 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:
*=,
*<>,
*<,
*<=,
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 t
Steve Singer 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:
> *=,
> *<>,
> *<,
> *<=,
> *>, and
> *>=.
>
> These operators c
On 09/28/2013 03:03 PM, Kevin Grittner wrote:
+To support matching of rows which include elements without a default
+B-tree operator class, the following operators are defined for composite
+type comparison:
+*=,
+*<>,
+*<,
+*<=,
+*>, and
+*>=.
+These oper
Kevin Grittner wrote:
> 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.
First draft attached.
> I'm inclined to first submit a proposed documentation patch for the
> exist
Bruce Momjian 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 incr
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:
> 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 matvi
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 t
Stephen Frost wrote:
> On Friday, September 20, 2013, Kevin Grittner wrote:
>> Stephen Frost 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 doin
On Friday, September 20, 2013, Kevin Grittner wrote:
> Stephen Frost > 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 poi
Stephen Frost 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: http://www.enterprisedb.com
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 a
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.
>
> Here is attempt at a review of t
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
>
> *=
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 h
21 matches
Mail list logo
