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
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 |