Re: Fractal tree indexes para PostgreSQL

From: Emanuel Calvo <postgres(dot)arg(at)gmail(dot)com>
To: "Guillermo O(dot) Burastero" <linux(dot)gb(at)gmail(dot)com>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: Fractal tree indexes para PostgreSQL
Date: 2012-03-27 18:02:06
Message-ID: CAGHEX6b6cheHBM-q2OSmPuHQSNAehO54pE5WftFNFxej=DieFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

>> si dices "Fractal tree indexes" yo pienso en algún tipo de índice pero
>> innodb no es un tipo de índice sino un tipo de almacenamiento.
>>
>> [... googleando al respecto ...]
>>
>> http://en.wikipedia.org/wiki/TokuDB
>>
>> TokuDB es un tipo de almacenamiento al igual que InnoDB que implementa
>> "Fractal tree indexes" en lugar de b-tree
>
> Creo que este tipo de artículo sería más útil para evaluar fractal tree
> como reemplazo de btrees:
>
> http://en.oreilly.com/mysql2010/public/schedule/detail/13265
>
> Se ve interesante, pero obviamente hace falta un nivel de detalle mucho
> mayor para poder implementarlo.  En todo caso me imagino que el fractal
> tree sería solamente un nuevo tipo de "access method"; a diferencia de
> mysql no hace falta un fork de Postgres para implementarlo ... ah, la
> extensibilidad ...!
>

Aún así los b-tree si caben en memoria, siguen dando mejores resultados. Por lo
que en sistemas con bastante memoria y datos que quepan en ella,
conviene InnoDB.

Está en inglés, pero esta talk es muy buena (min ~14/16) escucharán a un alumno
preguntando respecto de eso y su respuesta [1]

[1] http://www.youtube.com/watch?v=dLFgJvVrzJ0

--
--
Emanuel Calvo

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Katia Hernández 2012-03-27 18:10:19 RE: numero de registros de consulta
Previous Message npolanco 2012-03-27 17:34:04 Re: numero de registros de consulta