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 B8EBB9DC854 for ; Fri, 20 Jan 2006 19:52:40 -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 11007-07 for ; Fri, 20 Jan 2006 19:52:42 -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 5B51F9DC83F for ; Fri, 20 Jan 2006 19:52:37 -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 k0KNqbHx006533; Fri, 20 Jan 2006 18:52:37 -0500 (EST) To: "Steinar H. Gunderson" cc: pgsql-performance@postgresql.org Subject: Re: [GENERAL] Creation of tsearch2 index is very slow In-reply-to: <20060120225751.GA27230@uio.no> References: <17454.1137771321@sss.pgh.pa.us> <20060120170452.GC31908@svana.org> <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> Comments: In-reply-to "Steinar H. Gunderson" message dated "Fri, 20 Jan 2006 23:57:51 +0100" Date: Fri, 20 Jan 2006 18:52:37 -0500 Message-ID: <6532.1137801157@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/379 X-Sequence-Number: 16857 "Steinar H. Gunderson" writes: > For the record: Could we do with a less-than-optimal split here? Yeah, I was wondering the same. The code is basically choosing two "seed" values to drive the index-page split. Intuitively it seems that "pretty far apart" would be nearly as good as "absolute furthest apart" for this purpose. The cost of a less-than-optimal split would be paid on all subsequent index accesses, though, so it's not clear how far we can afford to go in this direction. It's also worth considering that the entire approach is a heuristic, really --- getting the furthest-apart pair of seeds doesn't guarantee an optimal split as far as I can see. Maybe there's some totally different way to do it. regards, tom lane