"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 PROT
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
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
e
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
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_ clust
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 shou
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
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
(num_tupl
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
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 du
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
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 a
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 reg
Oh I can't read - ignore me :)
Teodor Sigaev wrote:
Changes from previous patch:
* add support for tsearch2
* add 'fuzzy' limit
* fixes
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgre
What changed between Try 1 and Try 2?
Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community
will agree, we will commit it to HEAD branch.
---(end of broadcast)---
TIP 6: explain analyze is your friend
I just built this, and noticed that the regression test for "opr_sanity"
fails with your patch. I attached the regression.diffs.
Sorry, this part isn't done yet, because we are waiting of community decision..
We don't add regression test yet.
If community don't like to include GIN in core, w
On Wed, 26 Apr 2006, Teodor Sigaev wrote:
>
> We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
> agree, we will commit it to HEAD branch.
>
> http://www.sigaev.ru/gin/gin.gz
> http://www.sigaev.ru/gin/README.txt
>
> Install:
> % cd pgsql
> % zcat gin.gz | patch -p0
> make
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will agree,
we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README.txt
Install:
% cd pgsql
% zcat gin.gz | patch -p0
make and initdb, install tsearch2
Changes from previous patch
On Fri, 7 Apr 2006, Martijn van Oosterhout wrote:
On Fri, Apr 07, 2006 at 05:05:12PM +0400, Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
agree, we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README
One addition - some results of Gin testing is available:
http://www.sai.msu.su/~megera/oddmuse/index.cgi/GinTest
Oleg
On Fri, 7 Apr 2006, Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
agree, we will commit it to HEAD branch.
http://www.sigaev.
On Fri, Apr 07, 2006 at 05:05:12PM +0400, Teodor Sigaev wrote:
> We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
> agree, we will commit it to HEAD branch.
>
> http://www.sigaev.ru/gin/gin.gz
> http://www.sigaev.ru/gin/README
Fantastic! I was thinking about this a while
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will agree,
we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README
Install:
% cd pgsql
% zcat gin.gz | patch -p0
make and initdb
README:
Gin for PostgreSQL
Gin stands for Generali
22 matches
Mail list logo
