There's a definitional issue here, which is what does it mean to be
counting index tuples. I think GIN could bypass the VACUUM error check
by always returning the heap tuple count as its index tuple count. This
One problem: ambulkdelete hasn't any access to heap or heap's statistics
Teodor Sigaev [EMAIL PROTECTED] writes:
One problem: ambulkdelete hasn't any access to heap or heap's statistics
(num_tuples in scan_index() and vacuum_index() in vacuum.c). So, ambulkdelete
can't set stats-num_index_tuples equal to num_tuples.
We could probably fix that by adding it to the
On Fri, Apr 28, 2006 at 10:14:09AM -0400, Tom Lane wrote:
Here I think it would be best to add an indclusterable column to pg_am.
Actually, does clustering on *any* current index type except btree make
sense? None of them have semantically interesting index ordering
AFAIR, so maybe we should
We could probably fix that by adding it to the stats structs that are
passed around during VACUUM. I'd rather not hardwire a GIN special case
in vacuum.c as per your quick hack.
ok. amskipcheck?
Here I think it would be best to add an indclusterable column to pg_am.
GIN is _always_
Teodor Sigaev [EMAIL PROTECTED] writes:
We could probably fix that by adding it to the stats structs that are
passed around during VACUUM. I'd rather not hardwire a GIN special case
in vacuum.c as per your quick hack.
ok. amskipcheck?
Oh, I was thinking of having VACUUM put the heap tuple
ok. amskipcheck?
Oh, I was thinking of having VACUUM put the heap tuple count into the
struct and then amvacuumcleanup could copy it over to the index tuple
count. A skipcheck flag only solves the cosmetic problem of not
getting the warning, it doesn't fix things so that the correct count
Teodor Sigaev [EMAIL PROTECTED] writes:
Huh? Why two? Either you are allowed to cluster on indexes of this
type, or you're not. I don't see the point of any other distinction.
amclusterable - as you suggest: Does cluster command something or not?
This is what we need.
amclustered -
Takes clustering into account means nothing. We don't need that. Any
such consideration would be handled by the AM-specific amcostestimate
function.
Ok, I see. Sorry for misunderstanding. I thought that planner use that.
--
Teodor Sigaev E-mail: [EMAIL
I took the liberty of revising your README.txt as a native speaker :) I
cleaned up the grammar a lot, etc.
Thank you very much. I added your README to patch.
New version of GIN is available:
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README.txt
Changes from Try 2:
* add
Teodor Sigaev wrote:
* GIN stores several ItemPointer to heap tuple, so VACUUM FULL produces
this warning message:
WARNING: index idx contains 88395 row versions, but table contains
51812 row versions
HINT: Rebuild the index with REINDEX.
We
Alvaro Herrera [EMAIL PROTECTED] writes:
Teodor Sigaev wrote:
We appreciate any comments, help and suggestions. For third item we haven't
idea how fix it except to exclude GIN index from check.
How about adding a column to pg_am indicating these indexes must always
keep same tuple count as
How about adding a column to pg_am indicating these indexes must always
keep same tuple count as heap. This would be true for all current AMs,
false for GIN.
Yes, it's simplest solution, but it doesn't check of index consistency.
Possible, we can count number of itempointers to heap tuple
The ideal thing would be for GIN to return a count of the number of
distinct heap tuples referenced by the entries in the index, but I
suppose that would be impractical for VACUUM to compute.
Of course, in this case we should collect heap pointers in memory..
--
Teodor Sigaev
13 matches
Mail list logo
