Re: [PERFORM] encouraging index-only scans

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: [PERFORM] encouraging index-only scans
Дата
Msg-id 5229EB6F.4040306@krosing.net
обсуждение исходный текст
Ответ на Re: [PERFORM] encouraging index-only scans  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
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 <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.
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
>




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: get rid of SQL_ASCII?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII