Re: GSoC on WAL-logging hash indexes
От | Tan Tran |
---|---|
Тема | Re: GSoC on WAL-logging hash indexes |
Дата | |
Msg-id | CAOb=Yv1K=nuC=xDP5KGvwgOLx9pj8H-aCMqECB6ewq68ab9xyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GSoC on WAL-logging hash indexes (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: GSoC on WAL-logging hash indexes
|
Список | pgsql-hackers |
Thanks for alerting me to your previous idea. While I don't know enough about Postgresql internals to judge its merits yet, I'll write some pseudocode based on it in my proposal; and I'll relegate it to a "reach" proposal alongside a more straightforward one.
Tan
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Mar 2, 2014 at 2:38 PM, Tan Tran <tankimtran@gmail.com> wrote:Unfortunately, I don't believe that it's possible to do this easily
> 2. Proposal
> As a GSoC student, I will implement WAL recovery of hash indexes using the
> other index types' WAL code as a guide. Roughly, I will:
> - Devise a way to store and retrieve hashing data within the XLog data
> structures.
> - In the existing skeleton for hash_redo(XLogRecPtr lsn, XLogRecord *record)
> in hash.c, branch to code for the various redo operations: creating an
> index, inserting into an index, deleting an index, and page operations
> (split, delete, update?).
> - Code each branch by drawing on examples from btree_redo, gin_redo, and
> gist_redo, the existing XLog code of the other index types.
today because of the way bucket splits are handled. I wrote about
this previously here, with an idea for solving the problem:
http://www.postgresql.org/message-id/CA+TgmoZyMoJSrFxHXQ06G8jhjXQcsKvDiHB_8z_7nc7hj7iHYQ@mail.gmail.com
Sadly, no one responded. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: