Skip site navigation (1) Skip section navigation (2)

Re: On-disk bitmap index implementation

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>
Cc: <pgsql-patches(at)postgresql(dot)org>,"Jie Zhang" <jzhang(at)greenplum(dot)com>
Subject: Re: On-disk bitmap index implementation
Date: 2006-12-04 14:15:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Tue, 2006-12-05 at 00:18 +1100, Gavin Sherry wrote:

> o Determine if we need to provide anything for rm_startup, rm_cleanup,
>   rm_safe_restartpoint RmgrData function pointers.

safe_restartpoint gives true/false based upon whether there are
multi-record WAL states that have only been partially received. For
example, a btree index split needs multiple WAL records as it recurses
up the index tree. If you've got one record but not the others yet you
have an incomplete state and so cannot safely write a restartpoint.

I'll document that if you/anyone might suggest where the best place is?

> o Look into adding an AM option such that the user can determine word size
>   at index creation time. For higher-cardinality data (above 1000 distinct
>   values), 16 bit word sizes can really help with performance. Although
>   the word size is not just assumed to be a certain size across the code,
>   macros are used extensively to interact with the word size. Making it
>   different for each index might be a little messy.

...and is is it a typical case to have a bitmap with less than 1000
distinct values?? Surely we want that as the sole assumption?

Nearly unique bitmaps can suffer a little I think, if it makes the most
common case faster. But I'd like to see the perf results first, I guess.

  Simon Riggs             

In response to


pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-12-04 14:31:29
Subject: Re: zope connection string
Previous:From: Teodor SigaevDate: 2006-12-04 14:10:25
Subject: Bundle of patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group