Re: GIN, partial matches, lossy bitmaps

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GIN, partial matches, lossy bitmaps
Дата
Msg-id 17706.1236296124@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GIN, partial matches, lossy bitmaps  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: GIN, partial matches, lossy bitmaps
Re: GIN, partial matches, lossy bitmaps
Список pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
> Changes since 28.2
> (http://archives.postgresql.org/message-id/499B0FFA.8040608@sigaev.ru)

> - fixes/changes pointed by Robert
> (http://archives.postgresql.org/pgsql-hackers/2009-02/msg00987.php)
> - gingetbitmap will never throw error about lossiness of bitmap, it will return
> lossy bitmap even it was a prefix search.
> - remove tbm_check_tuple/tbm_has_lossy/tbm_max_non_lossy methods because they
> become unused
> - add new method tbm_add_page(TIDBitmap*, BlockNumber) to add the whole page to
> the TIDBitmap.

I cleaned up and applied the planner part of this, since that seems
reasonably useful in its own right for experimental index AMs,
regardless of where we settle out for GIN.  (The "cleanup" mostly
consisted of fixing it to not make extra calls to find_usable_indexes
--- that's an expensive function, and there's no very good reason to
run it another time rather than separating out the indexes afterwards.)

Attached is the remainder of the patch with relatively minor fixes.
The main change I made is to get rid of the changes in gincostestimate;
I agree with Robert that it's probably inappropriate to consider the
current pending-list size during planning.  I haven't really reviewed
any of the rest of it; this is just to have a clean patch against HEAD.

            regards, tom lane


Вложения

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

Предыдущее
От: Joshua Tolley
Дата:
Сообщение: Re: Make SIGHUP less painful if pg_hba.conf is not readable
Следующее
От: Josh Berkus
Дата:
Сообщение: Can we drop ABSTIME?