X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id DDF359DCA13 for ; Sat, 21 Jan 2006 16:56:29 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 45877-08 for ; Sat, 21 Jan 2006 16:56:31 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id C73879DC85A for ; Sat, 21 Jan 2006 16:56:27 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k0LKtnUh001750; Sat, 21 Jan 2006 15:56:29 -0500 (EST) To: David Lang cc: Ron , pgsql-performance@postgresql.org Subject: Re: [GENERAL] Creation of tsearch2 index is very In-reply-to: References: <26153.1137784469@sss.pgh.pa.us> <20060120201036.GE31908@svana.org> <26583.1137788505@sss.pgh.pa.us> <20060120205132.GF31908@svana.org> <26958.1137791955@sss.pgh.pa.us> <20060120213754.GG31908@svana.org> <7.0.1.0.2.20060120174141.039b03e8@earthlink.net> <6111.1137797436@sss.pgh.pa.us> <20060120225751.GA27230@uio.no> <6532.1137801157@sss.pgh.pa.us> <20060121000519.GA29755@uio.no> <6743.1137802990@sss.pgh.pa.us> <7.0.1.0.2.20060121064930.03aba810@earthlink.net> <18771.1137868073@sss.pgh.pa.us> Comments: In-reply-to David Lang message dated "Sat, 21 Jan 2006 12:19:26 -0800" Date: Sat, 21 Jan 2006 15:55:49 -0500 Message-ID: <1749.1137876949@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.095 required=5 tests=[AWL=0.095] X-Spam-Score: 0.095 X-Spam-Level: X-Archive-Number: 200601/400 X-Sequence-Number: 16878 David Lang writes: > On Sat, 21 Jan 2006, Tom Lane wrote: >> Ron writes: >>> Maybe we are over thinking this. What happens if we do the obvious >>> and just make a new page and move the "last" n/2 items on the full >>> page to the new page? >> >> Search performance will go to hell in a handbasket :-(. We have to make >> at least some effort to split the page in a way that will allow searches >> to visit only one of the two child pages rather than both. > does the order of the items within a given page matter? AFAIK the items within a GIST index page are just stored in insertion order (which is exactly why Ron's suggestion above doesn't work well). There's no semantic significance to it. It's only when we have to split the page that we need to classify the items more finely. regards, tom lane