Re: pg_advisor schema proof of concept - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: pg_advisor schema proof of concept
Date
Msg-id 4062C4CD.6000104@pse-consulting.de
Whole thread Raw
In response to Re: pg_advisor schema proof of concept  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-hackers
Christopher Kings-Lynne wrote:

>>> (6) possible inclusion in postgresql?
>>>  - among other contributions? what about contrib/advisor?
>>>  - added to template1 on default installation?
>>>    maybe not for a first release? or yes? it is easier to communicate
>>>    about
>>
>>
>> I think we're going to want a gborg project for 
>> developing/coordinating tests anyway. Having the schema included in 
>> contrib/ might help adoption, but so would pgadmin/phpgadmin. Any 
>> client-builders reading this? What do you think?
>
>
> Both phpPgAdmin (me) and the pgAdmin team have added or have thought 
> about adding some 'schema analysis' features to our products.  If 
> pg_advisor is available, I certainly won't bother and I will just 
> recommend to people that they install it.
>
> I think it probably should live in userland...

Yeah, this should live in userland.
Maybe this could be implemented as set of some descriptions, which is 
interpreted by a standalone tool, or interpreted by the gui tools 
available. This way, we could include a set of them into the admin tool 
distributions, ensuring a basic set is noticed by the admins (subject to 
update from contrib).

Currently, a check for old style fk triggers is hard-coded into pgadmin3 
(to detect missing adddepend), because fk triggers are considered 
internal and thus suppressed.

There are plans (and basic work) for a FK index tool, which wouldn't be 
obsolete if a pg_advisor would detect it because it's intended to have a 
checkbox "fix this" in the list of detected fks.

Regards,
Andreas




pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: subversion vs cvs (Was: Re: linked list rewrite)
Next
From: Yves Darmaillac
Date:
Subject: Re: Avoid MVCC using exclusive lock possible?