Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] GIN improvements

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] GIN improvements
Date: 2009-02-04 16:56:22
Message-ID: 4989C8B6.90802@sigaev.ru (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
> I looked at this a little bit --- it needs proofreading ("VACUUME"?).
Sorry, VACUUME fixed

> 
> Do we really need an additional column in pgstat table entries in
> order to store something that looks like it can be derived from the
> other columns?  The stats tables are way too big already.

It's not derived, because vacuum resets n_inserted_tuples to zero, but it 
doesn't reset tuples_inserted, tuples_updated and tuples_hot_updated. So, 
n_inserted_tuples is calculable until first vacuum occurs.



> Also, I really think it's a pretty bad idea to make index cost
> estimation depend on the current state of the index's pending list
> --- that state seems far too transient to base plan choices on.

I asked for that. v0.23 used statistic data by calling 
pg_stat_get_fresh_inserted_tuples(), so revert to that.
It's possible to add pending list information to IndexOptInfo, if it's acceptable.

> It's particularly got to be nuts to turn off indexscans entirely
> if the pending list is "too full".  Having some lossy pages might
> not be great but I don't believe it can be so bad that you should
> go to a seqscan all the time.

It's impossible to return "lossy page" via amgettuple interface. Although, with 
amgetbitmap it works well - and GIN will not emit error even bitmap becomes lossy.

In attached version, gincostestimate will disable index scan if estimation of 
number of matched tuples in pending list is greater than non-lossy limit of 
tidbitmap. That estimation is a product of indexSelectivity and number of tuples 
in pending list.

-- 
Teodor Sigaev                                   E-mail: teodor(at)sigaev(dot)ru
                                                    WWW: http://www.sigaev.ru/

Attachment: fast_insert_gin-0.26.gz
Description: application/x-tar (24.3 KB)

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2009-02-04 17:03:49
Subject: Re: Hot standby, recovery infra
Previous:From: Kevin GrittnerDate: 2009-02-04 16:48:00
Subject: Re: add_path optimization

pgsql-patches by date

Next:From: Jeff DavisDate: 2009-02-04 18:39:07
Subject: Re: [PATCHES] GIN improvements
Previous:From: Tom LaneDate: 2009-02-03 01:38:11
Subject: Re: [PATCHES] GIN improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group