Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 732489FA2EC for ; Tue, 10 Oct 2006 11:02:30 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 18512-02 for ; Tue, 10 Oct 2006 14:02:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 644029F9FB1 for ; Tue, 10 Oct 2006 11:02:25 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 9623A5643A; Tue, 10 Oct 2006 09:02:24 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Tue, 10 Oct 2006 09:02:22 -0500 Date: Tue, 10 Oct 2006 09:02:22 -0500 From: "Jim C. Nasby" To: "Joshua D. Drake" Cc: Tobias Brox , Chris Browne , pgsql-performance@postgresql.org Subject: Re: Simple join optimized badly? Message-ID: <20061010140222.GA72517@nasby.net> References: <20061009213303.GA19144@oppetid.no> <20061009223030.GW72517@nasby.net> <452AD005.1090101@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452AD005.1090101@commandprompt.com> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:061010:jd@commandprompt.com::0CETAVwrVdRpKyDY:00000000000000000 000000000000000000000000DBPa X-Hashcash: 1:20:061010:tobias@nordicbet.com::NokEzBsNR8qmrH4I:00000000000000000 0000000000000000000000000fJe X-Hashcash: 1:20:061010:cbbrowne@acm.org::dnH6R28ftfRsQ/Yx:01lK0 X-Hashcash: 1:20:061010:pgsql-performance@postgresql.org::j0kaNBgcolwjb9fQ:00000 00000000000000000000000046yJ X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200610/182 X-Sequence-Number: 21311 On Mon, Oct 09, 2006 at 03:41:09PM -0700, Joshua D. Drake wrote: > > > > One of the big problems with doing set enable_...=off is that there's no > > way to embed that into something like a view, so you're almost forced > > into putting into the application code itself, which makes matters even > > worse. If you could hint this within a query (maybe even on a per-table > > level), you could at least encapsulate that into a view. > > You can easily pass multiple statements within a single exec() or push > it into an SPF. Unless I'm missing something, putting multiple statements in a single exec means you're messing with the application code. And you can't update a SRF (also means messing with the application code). Though, I suppose you could update a view that pulled from an SRF... -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)