Re: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)
| От | Tom Lane |
|---|---|
| Тема | Re: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch) |
| Дата | |
| Msg-id | 15822.1185225568@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch) ("Simon Riggs" <simon@2ndquadrant.com>) |
| Ответы |
Re: Reviewing new index types (was Re: [PATCHES] Updatedbitmap indexpatch)
Re: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch) |
| Список | 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 по дате отправления: