Re: record identical operator

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: record identical operator
Date: 2013-09-24 13:31:53
Message-ID: 20130924133153.GR2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Kevin Grittner (kgrittn(at)ymail(dot)com) wrote:
> That's the point, and the whole point.  You have not shown that it
> doesn't.  You have not shown why adding a 12th non-default opclass
> is a particular problem here (although we have a consensus to use
> different operators, to reserve this operator namespace for other
> things). 

We need justification to add operators, imv, especially ones that expose
our internal binary representation of data. I worry that adding these
will come back to bite us later and that we're making promises we won't
be able to keep.

If these inconsistencies in what happens with these data types are an
issue then REFRESH can be handled as a wholesale DELETE/INSERT. Trying
to do this incremental-but-not-really maintenance where the whole query
is run but we try to skimp on what's actually getting updated in the
matview is a premature optimization, imv, and one which may be less
performant and more painful, with more gotchas and challenges for our
users, to deal with in the long run.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-09-24 13:46:12 Re: record identical operator
Previous Message Robert Haas 2013-09-24 13:29:01 Re: SSL renegotiation