Re: the number of pending entries in GIN index with FASTUPDATE=on - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: the number of pending entries in GIN index with FASTUPDATE=on
Date
Msg-id 20121128.111139.211353910.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: the number of pending entries in GIN index with FASTUPDATE=on  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: the number of pending entries in GIN index with FASTUPDATE=on
List pgsql-hackers
> > 1. This patch applies current git head cleanly, but installation
> >   ends up with failure because of the lack of
> >   pgstattuple--1.0--1.1.sql which added in Makefile.
> 
> Added pgstattuple--1.0--1.1.sql.

Good. Installation completed and ALTER EXTENSION UPDATE works
with that.

> > 2. I feel somewhat uneasy with size for palloc's (it's too long),
> >   and BuildTupleFromCString used instead of heap_from_tuple.. But
> >   it would lead additional modification for existent simillars.
> 
> OK. I changed the code as you suggested.

Thank you. It looks simpler than the last one. (although the way
differs to pgstatindex..)

> > 3. pgstatginidex shows only version, pending_pages, and
> >   pendingtuples. Why don't you show the other properties such as
> >   entry pages, data pages, entries, and total pages as
> >   pgstatindex does?
> 
> I didn't expose those because they are accurate as of last VACUUM.
> But if you think they are useful, I don't object to expose them.

Ok, my point was the apparent consistency of the functions. I
don't have any distinct wish about this.

I'll mark this as Ready for Committer.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PQconninfo function for libpq
Next
From: Bruce Momjian
Date:
Subject: Re: Further pg_upgrade analysis for many tables