Re: [PERFORM] encouraging index-only scans - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PERFORM] encouraging index-only scans
Date
Msg-id 20130906131207.GC600952@alap2.anarazel.de
Whole thread Raw
In response to Re: [PERFORM] encouraging index-only scans  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: [PERFORM] encouraging index-only scans
List pgsql-hackers
On 2013-09-06 13:38:56 +0200, Hannu Krosing wrote:
> On 09/06/2013 09:23 AM, Dimitri Fontaine wrote:
> > Alvaro Herrera <alvherre@2ndquadrant.com> 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.

> > 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

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PERFORM] encouraging index-only scans
Next
From: "MauMau"
Date:
Subject: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII