Re: [PATCHES] [Fwd: Index Advisor]

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PATCHES] [Fwd: Index Advisor]
Date: 2007-01-07 09:12:30
Message-ID: 1168161150.3951.66.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Sat, 2007-01-06 at 16:08 -0500, Bruce Momjian wrote:

> I have looked over this patch, and it completes part of this TODO item:
>
> o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
> ANALYZE, and CLUSTER

> It involves a patch to the backend, and a /contrib module to access it.
>
> I think we have to decide if we want this, and whether it should be in
> /contrib or fully integrated into the backend. 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 patch to the backend is in the form of a plugin API, which does
nothing when there is no plugin. IMHO there is a significant amount of
code there and it is too early to try to get all of that into the
backend, especially when more tested things like Tsearch2 haven't.
Plugins are cool because we can update them without needing to bounce a
production server, which means the code can evolve faster than it would
do if it was directly in the backend. (You do need to reconnect to allow
local_preload_libraries to be re-read). Tuning out the wierd
recommendations will take some time/effort - I don't know there are any,
but then my gut tells me there very likely are some.

The output isn't a system table, its a user space table. The reason for
having an output table is that we can use multiple invocations of the
adviser to build up a set of new indexes for a complete workload.
Reading things back out of the log would make that more difficult, since
we really want this to be automated by pgAdmin et al.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2007-01-07 09:25:32 security definer default for some PL languages (SQL/PSM)?
Previous Message Pavel Stehule 2007-01-07 08:59:52 proposal: catch warnings

Browse pgsql-patches by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2007-01-07 11:00:21 fix build on Solaris 10/x86_64 in 64bit mode with Sun Studio 11
Previous Message Peter Eisentraut 2007-01-07 08:57:04 Re: SGML index build fix