On Sun, Jan 31, 2010 at 3:36 PM, Tom Lane wrote:
> Back in September I wrote:
>> ... The sticking point --- not only for pg_class,
>> but for shared catalogs such as pg_database --- is the lack of a
>> way to track relfilenode if it ever changes. What if we keep
>> the relfilenode of these critic
Back in September I wrote:
> ... The sticking point --- not only for pg_class,
> but for shared catalogs such as pg_database --- is the lack of a
> way to track relfilenode if it ever changes. What if we keep
> the relfilenode of these critical tables someplace else? For
> instance, we could have
On Fri, Sep 4, 2009 at 9:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane wrote:
>>> Hmm ... reading that over again, it seems like there is a pretty
>>> obvious solution.
>
>> This doesn't seem totally horrible. But, before you go do it, do we
>> have a cl
Robert Haas writes:
> On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane wrote:
>> Hmm ... reading that over again, it seems like there is a pretty
>> obvious solution.
> This doesn't seem totally horrible. But, before you go do it, do we
> have a clearly-defined plan for the rest of the project?
Rest of
On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane wrote:
> I wrote:
>> Alvaro Herrera writes:
>>> No problem, just CLUSTER that table same as today.
>
>> Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
>> can't change its relfilenode. If you do, backends won't know where to
>> read
On Fri, Sep 4, 2009 at 2:48 PM, Tom Lane wrote:
> Josh Berkus writes:
I have a client who uses temp tables heavily, hundreds of thousands of
creates
and drops per day. They also have long running queries. The only
thing that
keeps catalog bloat somewhat in check is vacuum
Alvaro Herrera writes:
> The relcache need to be bootstrapped more than once, not just at
> initdb's bootstrap. (I guess you could try a breakpoint in formrdesc)
Ok so in RelationCacheInitializePhase3 we have formrdesc calls:
formrdesc("pg_class", false,
Dimitri Fontaine writes:
> Well at bootstrap time I guess noone is able to disturb the system by
> placing a concurrent CLUSTER pg_class; call. Once started, do those rels
> still need to have a special behavior?
It doesn't matter, if you fail to get past bootstrap because you
couldn't find pg_cl
Dimitri Fontaine escribió:
> Alvaro Herrera writes:
> > Dimitri Fontaine escribió:
> >> Why can't MVCC apply here? You'd have two versions of the pg_class entry
> >> that just has been CLUSTERed, and you keep the old relfilenode arround
> >> too. MVCC applies, and you teach vacuum to clean out the
Alvaro Herrera writes:
> Dimitri Fontaine escribió:
>> Why can't MVCC apply here? You'd have two versions of the pg_class entry
>> that just has been CLUSTERed, and you keep the old relfilenode arround
>> too. MVCC applies, and you teach vacuum to clean out the old file when
>> cleaning out the no
Dimitri Fontaine escribió:
> Hi,
>
> Tom Lane writes:
> > Alvaro Herrera writes:
> >> No problem, just CLUSTER that table same as today.
> >
> > Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
> > can't change its relfilenode. If you do, backends won't know where to
> > r
Hi,
Tom Lane writes:
> Alvaro Herrera writes:
>> No problem, just CLUSTER that table same as today.
>
> Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
> can't change its relfilenode. If you do, backends won't know where to
> read pg_class to find out its relfilenode.
Wh
I wrote:
> Alvaro Herrera writes:
>> No problem, just CLUSTER that table same as today.
> Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
> can't change its relfilenode. If you do, backends won't know where to
> read pg_class to find out its relfilenode.
> I was wondering
Alvaro Herrera writes:
> No problem, just CLUSTER that table same as today.
Uh, no, that was Josh's point: you can't CLUSTER pg_class, because you
can't change its relfilenode. If you do, backends won't know where to
read pg_class to find out its relfilenode.
I was wondering whether maintenance
Joshua D. Drake escribió:
> On Fri, 2009-09-04 at 15:10 -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > I'm confused. Are you saying that pg_class will never get bloated, so
> > > we don't need a way to debloat it? I realize that with HOT bloat is
> > > much less of a problem than it used t
On Fri, 2009-09-04 at 15:10 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I'm confused. Are you saying that pg_class will never get bloated, so
> > we don't need a way to debloat it? I realize that with HOT bloat is
> > much less of a problem than it used to be, but surely it's not
> > altoge
Robert Haas writes:
> I'm confused. Are you saying that pg_class will never get bloated, so
> we don't need a way to debloat it? I realize that with HOT bloat is
> much less of a problem than it used to be, but surely it's not
> altogether impossible...
Well, it's certainly *possible*, I'm just
Tom Lane írta:
> Josh Berkus writes:
>
I have a client who uses temp tables heavily, hundreds of thousands of
creates
and drops per day. They also have long running queries. The only
thing that
keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>>
Josh Berkus writes:
>>> I have a client who uses temp tables heavily, hundreds of thousands of
>>> creates
>>> and drops per day. They also have long running queries. The only
>>> thing that
>>> keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>> a few times a day. With
>
All,
>>> I have a client who uses temp tables heavily, hundreds of thousands of
>>> creates
>>> and drops per day. They also have long running queries. The only
thing that
>>> keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>> a few times a day. With
Actually, this is a
20 matches
Mail list logo
