On Fri, Feb 6, 2009 at 5:45 PM, Euler Taveira de Oliveira
wrote:
> Alvaro Herrera escreveu:
>>> (ii) I think we should change the expression "storage parameters" for
>>> something else because autovacuum is related to maintenance. My suggestion
>>> is
>>> a general expression like "relation param
Alvaro Herrera escreveu:
>> (ii) I think we should change the expression "storage parameters" for
>> something else because autovacuum is related to maintenance. My suggestion is
>> a general expression like "relation parameters";
>
> I'm not sure I agree with this idea, because the term "storage
Euler Taveira de Oliveira escribió:
> (i) I don't like this construction "by entries by changing storage
> parameters". I prefer "by changing storage parameters" or "by entries in
> pg_class.reloptions";
Heh, obvious "by entries by" is a cut'n'pasto; fixed.
Maybe an xref would be better there.
Alvaro Herrera escreveu:
> So here's what looks like a committable patch.
>
> Note to self: remember to remove src/include/catalog/pg_autovacuum.h and
> to bump catversion.
>
>
Works for me. Just a few comments.
(i) I don't like this construction "by entries by changing storage
parameters". I p
Alvaro Herrera escribió:
> Here's my proposed patch. There is a bug in the handling of TOAST
> tables; I'm sending this as a WIP to add it to the commitfest status
> page for this patch.
Sorry, that was a really stupid bug.
--
Alvaro Herrerahttp://www.CommandPro
Alvaro Herrera wrote:
Euler Taveira de Oliveira escribió:
Alvaro Herrera escreveu:
Alvaro Herrera escribió:
I have a separate branch on which I keep the old patch from Euler
updated to the current reloptions code; so it is probably very similar
to what Euler just sent. (I'll have a look at t
Euler Taveira de Oliveira escribió:
> Alvaro Herrera escreveu:
> > Alvaro Herrera escribió:
> >
> >> I have a separate branch on which I keep the old patch from Euler
> >> updated to the current reloptions code; so it is probably very similar
> >> to what Euler just sent. (I'll have a look at tha
Alvaro Herrera escreveu:
> Alvaro Herrera escribió:
>
>> I have a separate branch on which I keep the old patch from Euler
>> updated to the current reloptions code; so it is probably very similar
>> to what Euler just sent. (I'll have a look at that soon anyway.)
>
> Huh, nevermind -- I thought
Alvaro Herrera escribió:
> I have a separate branch on which I keep the old patch from Euler
> updated to the current reloptions code; so it is probably very similar
> to what Euler just sent. (I'll have a look at that soon anyway.)
Huh, nevermind -- I thought that Euler had just sent an updated
Robert Haas escribió:
> On Sun, Jan 11, 2009 at 6:47 PM, Euler Taveira de Oliveira
> wrote:
> > Robert Haas escreveu:
> >> Several things related to this patch have been committed:
> >>
> >> http://archives.postgresql.org/message-id/20081219143958.6f2dd756...@cvs.postgresql.org
> >> http://archive
On Sun, Jan 11, 2009 at 6:47 PM, Euler Taveira de Oliveira
wrote:
> Robert Haas escreveu:
>> Several things related to this patch have been committed:
>>
>> http://archives.postgresql.org/message-id/20081219143958.6f2dd756...@cvs.postgresql.org
>> http://archives.postgresql.org/message-id/20090105
Robert Haas escreveu:
> Several things related to this patch have been committed:
>
> http://archives.postgresql.org/message-id/20081219143958.6f2dd756...@cvs.postgresql.org
> http://archives.postgresql.org/message-id/20090105171428.77b29754...@cvs.postgresql.org
> (and several follow-on commits)
> Here is the patch that replace pg_autovaccum catalog with reloptions. I
> refactored the reloptions.c to support multiple parameters and made the
> action of adding a new option an easy task. I'm testing it yet, so don't
> expect it to work properly. I'll prepare docs as soon as I finish the
> te
Euler Taveira de Oliveira escreveu:
> [Sorry for the delay. I'm preparing the final patch and in a day or so
> I'll post it.]
>
Here is the patch that replace pg_autovaccum catalog with reloptions. I
refactored the reloptions.c to support multiple parameters and made the
action of adding a new op
Euler Taveira de Oliveira <[EMAIL PROTECTED]> wrote:
> We will have an official function (getRelOptions()?) to extract the
> reloption (autovacuum) parameters
Yeah, I want it, but...
> because we need to transform
> pg_autovacuum catalog table in a view to maintain backward compatibility.
I do
Euler Taveira de Oliveira wrote:
> We will have an official function (getRelOptions()?) to extract the
> reloption (autovacuum) parameters because we need to transform
> pg_autovacuum catalog table in a view to maintain backward compatibility.
Why? I'd say don't waste your time. If anything, it
ITAGAKI Takahiro escreveu:
[Sorry for the delay. I'm preparing the final patch and in a day or so
I'll post it.]
> I have a comment about reloptions of autovacuum parameters:
> I'd like to have an easier way to extract individual parameters.
>
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
>> Eu
I have a comment about reloptions of autovacuum parameters:
I'd like to have an easier way to extract individual parameters.
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Euler Taveira de Oliveira wrote:
> > What did I already do? I refactored reloptions.c to support multiple
> > options. I tried t
Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
> > So I gave up waiting for someone else to do the reloptions patch for
> > autovacuum and started work on it myself. What I soon discovered is
> > that on first blush it seems a lot easier than I had expected.
> >
> Sorry about that. :
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Okay, so I'll let you deal with this for a while yet. A minor
> suggestion: label the enum members distinctively, i.e. instead of
> RO_BOOL perhaps use RELOPT_TYPE_BOOL, and RO_HEAP should be
> RELOPT_KIND_HEAP (note this cannot be a plain enum, each ca
Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
>
> > Maybe we could add a "category" bitmask for which each option would be
> > valid.
> >
> The category tests are fine, that's why I introduced relopt_gen.kind but
> I'm not using it yet.
Ah, right, I hadn't noticed the kind stuff, m
Alvaro Herrera escreveu:
> Maybe we could add a "category" bitmask for which each option would be
> valid.
>
The category tests are fine, that's why I introduced relopt_gen.kind but
I'm not using it yet. I'll try to refactor it to use bitmask (some
options could be used to both -- fillfactor) and
Euler Taveira de Oliveira wrote:
> What did I already do? I refactored reloptions.c to support multiple
> options. I tried to follow up the same way GUC do (of course, it is much
> simpler). I'm thinking about removing (replacing?) StdRdOptions 'cause
> we need a different struct to store relopti
Alvaro Herrera escreveu:
> So I gave up waiting for someone else to do the reloptions patch for
> autovacuum and started work on it myself. What I soon discovered is
> that on first blush it seems a lot easier than I had expected.
>
Sorry about that. :( I was swamped with PGCon Brasil and then I
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> God, no. GUC is hopelessly complex already, we should *not* try to make
>> it track different values of a parameter for different tables.
> Are there any more specific reasons than "it's very complex"?
That one seems quite suffici
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
I wonder if we could piggy-back on guc parameters.
God, no. GUC is hopelessly complex already, we should *not* try to make
it track different values of a parameter for different tables.
Are there any more specific reasons than "it's
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>> So I gave up waiting for someone else to do the reloptions patch for
>> autovacuum and started work on it myself.
> Is it needed to keep backward compatibility?
> I'd like to suggest to keep pg_catalog.pg_
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> So I gave up waiting for someone else to do the reloptions patch for
> autovacuum and started work on it myself.
Is it needed to keep backward compatibility?
I'd like to suggest to keep pg_catalog.pg_autovacuum as a system view
even after the options i
Gregory Stark <[EMAIL PROTECTED]> writes:
> I wonder if we could piggy-back on guc parameters.
God, no. GUC is hopelessly complex already, we should *not* try to make
it track different values of a parameter for different tables.
Attaching a reloptions-like column to pg_tablespace might not be
u
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Before we waste too much time thinking how this registering is to be
> done, does anybody think that the current approach is OK and thus I
> should just add the autovacuum options directly into StdRdOptions and
> default_reloptions?
Given Simon's sugge
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, OK. However, given that the various AMs amoptions also use
> default_reloptions, they are going to accept the autovacuum options too.
> Is that OK?
Well, we might want to split default_reloptions into two versions,
one for heaps and the other for
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On second look, however, the problem is that I seem to be
> > forced to declare all the autovacuum-related options and their parsing
> > properties in reloptions.c. This seems very ugly.
>
> That was in fact the intended design, and
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On second look, however, the problem is that I seem to be
> forced to declare all the autovacuum-related options and their parsing
> properties in reloptions.c. This seems very ugly.
That was in fact the intended design, and is why the functions exist
So I gave up waiting for someone else to do the reloptions patch for
autovacuum and started work on it myself. What I soon discovered is
that on first blush it seems a lot easier than I had expected.
On second look, however, the problem is that I seem to be
forced to declare all the autovacuum-re
34 matches
Mail list logo
