Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VHxMU-0007Gz-NE for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Sep 2013 14:50:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VHxMU-0004DG-7E for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Sep 2013 14:50:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VHxMT-0004Cu-DD for pgsql-hackers@postgresql.org; Fri, 06 Sep 2013 14:50:13 +0000 Received: from moutng.kundenserver.de ([212.227.17.10]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VHxML-0005qP-4i for pgsql-hackers@postgresql.org; Fri, 06 Sep 2013 14:50:13 +0000 Received: from [192.168.11.106] (62.175.246.114.static.riosat.com [62.175.246.114]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LgeHd-1VnQbd1MI9-00oZYW; Fri, 06 Sep 2013 16:49:30 +0200 Message-ID: <5229EB6F.4040306@krosing.net> Date: Fri, 06 Sep 2013 16:49:19 +0200 From: Hannu Krosing User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andres Freund CC: Hannu Krosing , Dimitri Fontaine , Alvaro Herrera , Bruce Momjian , Robert Haas , Peter Geoghegan , Tom Lane , Andrew Dunstan , PostgreSQL-development Subject: Re: [PERFORM] encouraging index-only scans References: <20121213024837.GB22363@momjian.us> <23298.1355370698@sss.pgh.pa.us> <20130904205655.GR21874@momjian.us> <20130906001437.GA29264@momjian.us> <20130906020043.GH27195@momjian.us> <20130906052236.GF6067@eldon.alvh.no-ip.org> <5229BED0.5070506@2ndQuadrant.com> <20130906131207.GC600952@alap2.anarazel.de> In-Reply-To: <20130906131207.GC600952@alap2.anarazel.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:tRkX/0MaJYj9jJ2VtcIYAb7rh5aB8unwZU45UU1pEmI UStpMVYKMJuEsexOoCwnp4eY2y10pGmRnk7+t8sGjuBVWn4jBY vfOqOSFofyH2/WEXXO3AMjBBMl1rUSFEm3cPKnOfgupz2o8rVw 39Vw/Q9Qfuyle665VG1OWoaI7uw5p2BNpaQchpFLrAPDQiwdnB EwhacUVfBy4K7EJvZXaHeKU1Ll3vxGdvN2J9ZnQJfrW/uVlKBe 9WcnDvbRyqZ+uMk05mxmKNFzgmju22I2rdxH1JB9JMmYpmUV8T tiKNbXmuI0jxyRPBtMpDjCWKowSGmagZwjUWzysBY9zAjQVzxe 91SzkJWZS0KwuGd88srM= X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 09/06/2013 03:12 PM, Andres Freund wrote: > On 2013-09-06 13:38:56 +0200, Hannu Krosing wrote: >> On 09/06/2013 09:23 AM, Dimitri Fontaine wrote: >>> Alvaro Herrera writes: >>>> I'm not sure if we need to expose all these new maintenance actions as >>>> SQL commands. >>> I strongly think we should, if only for diagnostic purposes. >> It would be much easier and more flexible to expose them >> as pg_*() function calls, not proper "commands". > I don't think that's as easy as you might imagine. For much of what's > done in that context you cannot be in a transaction, you even need to be > in a toplevel statement (since we internally > CommitTransactionCommand/StartTransactionCommand). > > So those pg_* commands couldn't be called (except possibly via the > fastpath function call API ...) which might restrict their usefulnes a > teensy bit ;) > > So, I think extending the options passed to VACUUM - since it can take > pretty generic options these days - is a more realistic path. Might be something convoluted like VACUUM indexname WITH (function = "pg_cleanup_gin($1)"); :) > >>> Also to >>> adapt to some well defined workloads that the automatic system is not >>> designed to handle. >> +1 > What would you like to expose individually? > > Greetings, > > Andres Freund > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers