Re: Fractal tree indexing - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Fractal tree indexing
Date
Msg-id CAM-w4HPRLs9ASA2+DguzoXg8QmY17+88AMnyCQYJZ7hrE=Jc4g@mail.gmail.com
Whole thread Raw
In response to Re: Fractal tree indexing  (Atri Sharma <atri.jiit@gmail.com>)
Responses Re: Fractal tree indexing
Re: Fractal tree indexing
List pgsql-hackers
On Wed, Feb 13, 2013 at 10:19 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
>> 2) Tokutek can't provide full-fledged fractal tree indexes as PostgreSQL
>> extension because lack of WAL extensibility.
>> We could think about WAL extensibility which would help other applications
>> as well.
>>
>
> Sounds nice. WAL extensibility can help.

The problem with WAL extensibility is that extensions can come and go
and change over time. If the database can't interpret some WAL record
or misinterprets it because a module is missing or changed since that
record was written then you could lose your whole database. I think a
fundamental part of extensibility is isolating the effects of the
extensions from the rest of the system so that problem would have to
be tackled. Perhaps making each file owned by a single resource
manager and having the database be able to deal with individual files
being corrupted. But that doesn't deal with all record types and there
are situations where you really want to have part of a file contain
data managed by another resource manager.

Heikki was talking about a generic WAL record type that would just
store a binary delta between the version of the block when it was
locked and when it was unlocked. That would handle any extension
cleanly as far as data modification goes as long as the extension was
working through our buffer manager. It seems like an attractive idea
to me.

-- 
greg



pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: Fractal tree indexing
Next
From: Amit Kapila
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]