Re: pageinspect: Hash index support

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: pageinspect: Hash index support
Дата
Msg-id CAMkU=1wghadVOxkphJTQUqukgNkE7ETPci0g55Y+fqXO4Q43PQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pageinspect: Hash index support  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: pageinspect: Hash index support  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Список pgsql-hackers
On Tue, Aug 30, 2016 at 10:06 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Jesper Pedersen wrote:
> Hi,
>
> Attached is a patch that adds support for hash indexes in pageinspect.
>
> The functionality (hash_metap, hash_page_stats and hash_page_items) follows
> the B-tree functions.

I suggest that pageinspect functions are more convenient to use via the
get_raw_page interface, that is, instead of reading the buffer
themselves, the buffer is handed over from elsewhere and they receive it
as bytea.  This enables other use cases such as grabbing a page from one
server and examining it in another one.

I've never needed to do that, but it does sound like it might be useful.  But it is also annoying to have to do that when you want to examine a current server.  Could we use overloading, so that it can be used in either way?



For hash_page_items, the 'data' is always a 32 bit integer, isn't it? (unlike other pageinspect features, where the data could be any user-defined data type).  If so, I'd rather see it in plain hex (without the spaces, without the trailing zeros)

+   /* page type (flags) */
+   if (opaque->hasho_flag & LH_UNUSED_PAGE)
+       stat->type = 'u';

This can never be true, because LH_UNUSED_PAGE is zero.  You should make this be the fall-through case, and have LH_META_PAGE be explicitly tested for.

Cheers,

Jeff

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: New SQL counter statistics view (pg_stat_sql)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: What is the posix_memalign() equivalent for the PostgreSQL?