Re: [PATCHES] [Fwd: Index Advisor]
| От | Gurjeet Singh |
|---|---|
| Тема | Re: [PATCHES] [Fwd: Index Advisor] |
| Дата | |
| Msg-id | 65937bea0701070542k3f7f20e2k26c185d8073eefec@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCHES] [Fwd: Index Advisor] (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: [PATCHES] [Fwd: Index Advisor]
|
| Список | pgsql-hackers |
On 1/7/07, Bruce Momjian <bruce@momjian.us> wrote:
Thanks
Well, as already said, the plugin architecture gives others a way to develop and deploy their own index advisers, or even something else that does nifty things with the generated plan!
The advise_index table not required to be a system table anymore, as required by the original patch. It can be any table/view on which the executing user has INSERT permissions. The Adviser internally builds an 'INSERT INTO advise_index ...' statement and executes it through SPI. So, it actually behaves as if the user is doing and INSERT. As a side effect, if the EXPLAIN is done in a transaction, which is later rolled back, the recommendations inserted in the advise_index will also be lost!
contrib/pg_advise_index/sample_error_messages.txt also shows an interesting usage, where advise_index is actually a VIEW with a RULE that redirects INSERTs into another advise_index_data table.
Best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
I have looked over this patch,
Thanks
I think we have to decide if we want this, and whether it should be in
/contrib or fully integrated into the backend.
Well, as already said, the plugin architecture gives others a way to develop and deploy their own index advisers, or even something else that does nifty things with the generated plan!
I am thinking the API
needs to be simpified, perhaps by removing the system table and having
the recommendations just logged to the server logs.
The advise_index table not required to be a system table anymore, as required by the original patch. It can be any table/view on which the executing user has INSERT permissions. The Adviser internally builds an 'INSERT INTO advise_index ...' statement and executes it through SPI. So, it actually behaves as if the user is doing and INSERT. As a side effect, if the EXPLAIN is done in a transaction, which is later rolled back, the recommendations inserted in the advise_index will also be lost!
contrib/pg_advise_index/sample_error_messages.txt also shows an interesting usage, where advise_index is actually a VIEW with a RULE that redirects INSERTs into another advise_index_data table.
Best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
В списке pgsql-hackers по дате отправления: