On 16 October 2012 04:49, Peter Eisentraut wrote:
> On Mon, 2012-10-15 at 11:14 -0700, Josh Berkus wrote:
>> I'd be in favor of a warning on create index.
>
> Only if you can turn it off, please.
>
> But I don't think a warning is appropriate if the statement does exactly
> what the user wanted.
On Mon, 2012-10-15 at 11:14 -0700, Josh Berkus wrote:
> I'd be in favor of a warning on create index.
Only if you can turn it off, please.
But I don't think a warning is appropriate if the statement does exactly
what the user wanted. The place to point out shortcomings of the
implementation is i
On 15 October 2012 20:04, Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:49 AM, Andres Freund
> wrote:
>> On Monday, October 15, 2012 08:46:40 PM Jeff Janes wrote:
>>> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>>> > I would be in favor of moving them to contrib for 9.4. Assuming tha
On Mon, Oct 15, 2012 at 11:46:40AM -0700, Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
> >
> > I would be in favor of moving them to contrib for 9.4. Assuming that
> > someone can figure out how this interacts with the existing system table
> > opclasses. Them being i
On Mon, Oct 15, 2012 at 11:49 AM, Andres Freund wrote:
> On Monday, October 15, 2012 08:46:40 PM Jeff Janes wrote:
>> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>> > I would be in favor of moving them to contrib for 9.4. Assuming that
>> > someone can figure out how this interacts with
On 15 October 2012 19:46, Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>>
>> I would be in favor of moving them to contrib for 9.4. Assuming that
>> someone can figure out how this interacts with the existing system table
>> opclasses. Them being in /contrib would al
On Monday, October 15, 2012 08:46:40 PM Jeff Janes wrote:
> On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
> > I would be in favor of moving them to contrib for 9.4. Assuming that
> > someone can figure out how this interacts with the existing system table
> > opclasses. Them being in /con
On Mon, Oct 15, 2012 at 11:14 AM, Josh Berkus wrote:
>
> I would be in favor of moving them to contrib for 9.4. Assuming that
> someone can figure out how this interacts with the existing system table
> opclasses. Them being in /contrib would also put less pressure on the
> next new hacker who d
On Monday, October 15, 2012 08:14:51 PM Josh Berkus wrote:
> > * Put WARNINGs in the docs against the use of hash indexes, backpatch
> > to 8.3. CREATE INDEX gives no warning currently, though Index Types
> > does mention a caution.
>
> I'd be in favor of a warning on create index.
>
> Also, are
Simon,
> * Put WARNINGs in the docs against the use of hash indexes, backpatch
> to 8.3. CREATE INDEX gives no warning currently, though Index Types
> does mention a caution.
I'd be in favor of a warning on create index.
Also, are hash indexes replicated?
> * Mention in the current docs that ha
On Mon, Oct 15, 2012 at 10:13:24AM -0400, Robert Haas wrote:
> On Sun, Oct 14, 2012 at 9:45 AM, Simon Riggs wrote:
> > * Put WARNINGs in the docs against the use of hash indexes, backpatch
> > to 8.3. CREATE INDEX gives no warning currently, though Index Types
> > does mention a caution.
>
> I'd
On 15 October 2012 18:07, Robert Haas wrote:
> On Mon, Oct 15, 2012 at 12:59 PM, Simon Riggs wrote:
>>> I don't think I'd go so far as to say that we should
>>> imply that they'll be removed in a future release. Given how deeply
>>> intertwined they are with the planner, I doubt that that will h
On Monday, October 15, 2012 07:03:35 PM Simon Riggs wrote:
> On 15 October 2012 15:19, Andres Freund said...
>
> > I vote for at least logging a wal record when a hash index is modified
> > which uses incomplete actions to set 'indisready = false' in case its
> > replayed. That should only use a r
On Mon, Oct 15, 2012 at 12:59 PM, Simon Riggs wrote:
>> I don't think I'd go so far as to say that we should
>> imply that they'll be removed in a future release. Given how deeply
>> intertwined they are with the planner, I doubt that that will happen;
>> and I think there is enough interest in t
On 15 October 2012 15:19, Andres Freund said...
> I vote for at least logging a wal record when a hash index is modified which
> uses incomplete actions to set 'indisready = false' in case its replayed. That
> should only use a rather minor amount of code and should help users to find
> problems f
On 15 October 2012 15:13, Robert Haas wrote:
> On Sun, Oct 14, 2012 at 9:45 AM, Simon Riggs wrote:
>> * Put WARNINGs in the docs against the use of hash indexes, backpatch
>> to 8.3. CREATE INDEX gives no warning currently, though Index Types
>> does mention a caution.
>
> I'd be in favor of addi
On Sunday, October 14, 2012 03:45:49 PM Simon Riggs wrote:
> As discussed on other threads, Hash Indexes are currently a broken
> feature and bring us into disrepute.
>
> I describe them as broken because they are neither crash safe, nor
> could they properly be called unlogged indexes (or if so,
On Sun, Oct 14, 2012 at 9:45 AM, Simon Riggs wrote:
> * Put WARNINGs in the docs against the use of hash indexes, backpatch
> to 8.3. CREATE INDEX gives no warning currently, though Index Types
> does mention a caution.
I'd be in favor of adding such warnings to the documentation if they
are not
On 14 October 2012 17:47, Tom Lane wrote:
> Simon Riggs writes:
>> As discussed on other threads, Hash Indexes are currently a broken
>> feature and bring us into disrepute.
>
> Yeah ...
>
>> Suggested actions are
>
> I find it curious that you don't even bother to list "add WAL support to
> hash
Simon Riggs writes:
> As discussed on other threads, Hash Indexes are currently a broken
> feature and bring us into disrepute.
Yeah ...
> Suggested actions are
I find it curious that you don't even bother to list "add WAL support to
hash indexes" as a possible solution. It's certainly doable,
On 10/14/2012 09:45 AM, Simon Riggs wrote:
As discussed on other threads, Hash Indexes are currently a broken
feature and bring us into disrepute.
I describe them as broken because they are neither crash safe, nor
could they properly be called unlogged indexes (or if so, why just
hash?). And al
As discussed on other threads, Hash Indexes are currently a broken
feature and bring us into disrepute.
I describe them as broken because they are neither crash safe, nor
could they properly be called unlogged indexes (or if so, why just
hash?). And also because if somebody suggested implementing
22 matches
Mail list logo
