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 по дате отправления: