From: Teodor Sigaev <teodor@sigaev.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] GIN improvements
Date: Wed, 04 Feb 2009 19:56:22 +0300
Message-ID: <4989C8B6.90802@sigaev.ru> (raw)
In-Reply-To: <16080.1233625091@sss.pgh.pa.us>
References: <483FD205.4090904@sigaev.ru>
<486BC501.6060605@sigaev.ru>
<27880.1215810535@sss.pgh.pa.us>
<487A6E0C.3090600@sigaev.ru>
<8993.1216843701@sss.pgh.pa.us>
<4888A594.6010102@sigaev.ru>
<490B07BA.6030109@sigaev.ru>
<492F04D9.5070404@enterprisedb.com>
<4942A137.3000502@sigaev.ru>
<1229910966.2285.76.camel@jdavis>
<49708008.8070109@sigaev.ru>
<1232348905.7281.114.camel@jdavis>
<4974B002.3040202@sigaev.ru>
<1232474489.23316.8.camel@jdavis>
<49770FD4.5030600@sigaev.ru>
<1232561271.23793.46.camel@jdavis>
<497864DC.5080800@sigaev.ru>
<4979BAF8.1000501@sigaev.ru>
<16080.1233625091@sss.pgh.pa.us>
> 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@sigaev.ru
WWW: http://www.sigaev.ru/Attachments:
fast_insert_gin-0.26.gz (application/x-tar, 24.3K) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: teodor@sigaev.ru, tgl@sss.pgh.pa.us, pgsql@j-davis.com, heikki.linnakangas@enterprisedb.com, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] GIN improvements
In-Reply-To: <4989C8B6.90802@sigaev.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox