Re: Dynamic Partitioning using Segment Visibility Maps

Поиск
Список
Период
Сортировка
От Gokulakannan Somasundaram
Тема Re: Dynamic Partitioning using Segment Visibility Maps
Дата
Msg-id 9362e74e0801060024j4e6c3ee4maf189eabd3ab15b1@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dynamic Partitioning using Segment Visibility Maps  (tomas@tuxteam.de)
Список pgsql-hackers


On Jan 6, 2008 11:27 AM, <tomas@tuxteam.de> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jan 06, 2008 at 01:12:32AM +0530, Gokulakannan Somasundaram wrote:
> On Jan 5, 2008 6:15 PM, < tomas@tuxteam.de> wrote:
>
> >
> > One thought I had back then, with partitioned tables was "gee -- B-tree
> > index is already doing a partition; why do a manual partition on top of
> > that?".

> Can you please explain more on what you are trying to say here?

Sure. A B-tree is just a device to partition something along some order.
If you have , say, a table of orders (to use the example upthread) and a
B-tree index on order date, this index partitions your set (at
recursively finer levels).

But the current index scans - Index Scan and Bitmap  Index Scan, doesn't provide the exact benefit of partitioning, even if all the columns are covered by the index. It does a lot more disk reads than the partitioning scheme. I think you are looking for something like Block indexes in Multi-dimensional Clusters in DB2.  Heikki did something like that in a more subtle way.

Postgresql Clusters, as you may know doesn't maintain the order with inserts. We might go for Index Organized Tables/Clustered indexes. But then, B-tree would give lot of performance problems, if the Index Tuple size increases beyond a certain point.

Thanks,
Gokul.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Gokulakannan Somasundaram"
Дата:
Сообщение: Re: Dynamic Partitioning using Segment Visibility Maps
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Bug: Unreferenced temp tables disables vacuum to update xid