Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 9833163275B for ; Mon, 2 Feb 2009 21:38:21 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 96842-01 for ; Mon, 2 Feb 2009 21:38:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 8516C632702 for ; Mon, 2 Feb 2009 21:38:18 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n131cBja016081; Mon, 2 Feb 2009 20:38:11 -0500 (EST) To: Teodor Sigaev cc: Jeff Davis , Heikki Linnakangas , Pgsql Hackers Subject: Re: [PATCHES] GIN improvements In-reply-to: <4979BAF8.1000501@sigaev.ru> 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> Comments: In-reply-to Teodor Sigaev message dated "Fri, 23 Jan 2009 15:41:28 +0300" Date: Mon, 02 Feb 2009 20:38:11 -0500 Message-ID: <16080.1233625091@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200902/76 X-Sequence-Number: 133366 Teodor Sigaev writes: > I'm very sorry, but v0.24 has a silly bug with not initialized value :(. > New version is attached I looked at this a little bit --- it needs proofreading ("VACUUME"?). 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. 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. 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. regards, tom lane