Re: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)
Date
Msg-id 15822.1185225568@sss.pgh.pa.us
Whole thread Raw
In response to Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Reviewing new index types (was Re: [PATCHES] Updatedbitmap indexpatch)  ("Simon Riggs" <simon@2ndquadrant.com>)
Re: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:
> ... BMI is not useful at all
> for PKs, whilst GIT is specifically designed to handle them.

This seems a strange statement, because GIT doesn't look particularly
efficient for unique indexes AFAICS.  In the worst case you'd have to
look individually at each tuple on a heap page to check for uniqueness
conflict (no binary search, because you couldn't assume they are
ordered).

> B-TREE INDEXES (Integers) 

> Rows/value    Best time    Size in blocks
> 10000000    49s        21899
> 1000000        49s        21899
> 100000        49s        21899
> 10000        47s        21899
> 1000        43s        21899
> 100        38s        21899
> 10        38s        21899
> 1        33s        21899

Surely the GIT code failed to kick in at all here?  That's just about
exactly the index size I'd expect for 10 million integers with the
existing btree code (at least when MAXALIGN=4).
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)
Next
From: "Simon Riggs"
Date:
Subject: Re: Reviewing new index types (was Re: [PATCHES] Updatedbitmap indexpatch)