Re: [HACKERS] Interface for pg_autovacuum

2006-12-23 Thread Dave Page
Robert Treat wrote: Dave: How does PgAdmin handle setting table-specific autovacuum parameters? (Does it?) Yes, it adds/removes/edits rows in pg_autovacuum as required. We do this in phppgadmin too, although I also added a screen that show alist of entries with schema and table names (rather

Re: [HACKERS] Interface for pg_autovacuum

2006-12-22 Thread Robert Treat
On Thursday 21 December 2006 10:57, Dave Page wrote: > Simon Riggs wrote: > > On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote: > >> On the other hand, this would be the only part of the system where > >> the official interface/API is a system catalog table. Do we really > >> want to expose the i

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Tom Lane
"Jim Nasby" <[EMAIL PROTECTED]> writes: > The only other thought that comes to mind is that such syntax will > make it a *lot* more verbose to set all the options for a table. Which should surely make you wonder whether setting these options per-table is the most important thing to do... Arguin

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Jim Nasby
On Dec 21, 2006, at 1:28 PM, Andrew Dunstan wrote: Jim Nasby wrote: How about... ALTER TABLE ... ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ] ALTER AUTOANALYZE [ THRESHOLD | SCALE ] Given these remarks from Tom: Where we are currently at is experimenting to find out what

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Richard Huxton
Gregory Stark wrote: "Jim Nasby" <[EMAIL PROTECTED]> writes: How about... ALTER TABLE ... ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ] ALTER AUTOANALYZE [ THRESHOLD | SCALE ] ... or would that create a whole bunch of reserved words? The way to predict when you're going t

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Andrew Dunstan
Jim Nasby wrote: How about... ALTER TABLE ... ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ] ALTER AUTOANALYZE [ THRESHOLD | SCALE ] Given these remarks from Tom: Where we are currently at is experimenting to find out what autovacuum's control knobs ought to be. The catal

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Gregory Stark
"Jim Nasby" <[EMAIL PROTECTED]> writes: > How about... > > ALTER TABLE ... > ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ] > ALTER AUTOANALYZE [ THRESHOLD | SCALE ] > > ... or would that create a whole bunch of reserved words? The way to predict when you're going to run into c

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Jim Nasby
How about... ALTER TABLE ... ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ] ALTER AUTOANALYZE [ THRESHOLD | SCALE ] ... or would that create a whole bunch of reserved words? On Dec 21, 2006, at 10:04 AM, Simon Riggs wrote: On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote:

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Dave Page
Simon Riggs wrote: On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote: On the other hand, this would be the only part of the system where the official interface/API is a system catalog table. Do we really want to expose the internal representation of something as our API? That doesn't seem

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Simon Riggs
On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote: > On the other hand, this would be the only part of the system where > the official interface/API is a system catalog table. Do we really > want to expose the internal representation of something as our API? > That doesn't seem wise to me..

Re: [HACKERS] Interface for pg_autovacuum

2006-12-21 Thread Matthew O'Connor
Russell Smith wrote: I thought the plan was to change the ALTER TABLE command to allow vacuum settings to be set. That is my understanding too. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Interface for pg_autovacuum

2006-12-20 Thread Tom Lane
"Jim Nasby" <[EMAIL PROTECTED]> writes: > On the other hand, this would be the only part of the system where > the official interface/API is a system catalog table. I don't think it was ever intended by anyone that that would be the long-term solution. Where we are currently at is experimenting

Re: [HACKERS] Interface for pg_autovacuum

2006-12-20 Thread Russell Smith
Jim Nasby wrote: On Dec 20, 2006, at 7:56 AM, Florian G. Pflug wrote: Jim Nasby wrote: I'm teaching a class this week and a student asked me about OIDs. He related the story of how in Sybase, if you moved a database from one server from another, permissions got all screwed up because user IDs

Re: [HACKERS] Interface for pg_autovacuum

2006-12-20 Thread Jim Nasby
On Dec 20, 2006, at 7:56 AM, Florian G. Pflug wrote: Jim Nasby wrote: I'm teaching a class this week and a student asked me about OIDs. He related the story of how in Sybase, if you moved a database from one server from another, permissions got all screwed up because user IDs no longer matc

Re: [HACKERS] Interface for pg_autovacuum

2006-12-20 Thread Florian G. Pflug
Jim Nasby wrote: I'm teaching a class this week and a student asked me about OIDs. He related the story of how in Sybase, if you moved a database from one server from another, permissions got all screwed up because user IDs no longer matched. I explained that exposing something like an integer