Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7B3339FB2B3 for ; Wed, 17 Jan 2007 14:47:36 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 12826-04 for ; Wed, 17 Jan 2007 14:46:50 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by postgresql.org (Postfix) with ESMTP id 4CA599FB2BA for ; Wed, 17 Jan 2007 14:46:50 -0400 (AST) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 7E77E7DC74; Wed, 17 Jan 2007 13:46:40 -0500 (EST) Received: from web2.messagingengine.com ([10.202.2.211]) by out1.internal (MEProxy); Wed, 17 Jan 2007 13:46:40 -0500 Received: by web2.messagingengine.com (Postfix, from userid 99) id 5EA5526FD1; Wed, 17 Jan 2007 13:46:40 -0500 (EST) Message-Id: <1169059600.23210.1169763553@webmail.messagingengine.com> X-Sasl-Enc: Iia66AX9LFsIUIFdyvVPPZyQhMOVXYvO6PuxPc0FyJpj 1169059600 From: "Jeremy Haile" To: "Chad Wagner" Cc: "Tom Lane" , pgsql-performance@postgresql.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <1168982580.8275.1169588211@webmail.messagingengine.com> <26412.1168983547@sss.pgh.pa.us> <1168986053.16393.1169598917@webmail.messagingengine.com> <81961ff50701161444l3f932755m5a6e15ad2d948130@mail.gmail.com> <1169002739.19758.1169636285@webmail.messagingengine.com> <81961ff50701162052s4779103dq3f0314fe2ac17134@mail.gmail.com> <1169046562.24920.1169717849@webmail.messagingengine.com> <81961ff50701170926r3dd41f39u9e2d4a131b3c3097@mail.gmail.com> Subject: Re: PG8.2.1 choosing slow seqscan over idx scan In-Reply-To: <81961ff50701170926r3dd41f39u9e2d4a131b3c3097@mail.gmail.com> Date: Wed, 17 Jan 2007 13:46:40 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/269 X-Sequence-Number: 22870 > It would be nice if the database could > learn to estimate these values, as newer versions of Oracle does. That would be really nice since it would take some of the guess work out of it. > Yes, cluster would rebuild the table for you. I wouldn't do anything too > intrusive, run with the random_page_cost lowered, perhaps vacuum full, > reindex, and see what happens. I'll try doing the vacuum full and reindex tonight since they require exclusive locks. > Yep, my thoughts exactly. Partitioning support is PostgreSQL is there, > but it needs a bit more of a tighter integration into the core (I shouldn't > have to create a view, n tables, n rules, etc). Additionally, I have read > that at some point when you have "y" partitions the performance degrades, > haven't really looked into it myself. Yeah - I haven't setup partitioning in PostgreSQL before, although I've read quite a bit about it. I've talked about getting improved syntax for partitioning in PostgreSQL. MySQL's syntax is much simpler and more intuitive compared to setting them up with Postgres - it would be nice if PostgreSQL adopted a similar syntax where partitions were first-class citizens.