> > The count approach seems definitely the right way, but a check (possibly
> > a slow one) can be probably done without initdb.
>
> We can certainly do the proper fix in 7.4; do we consider this bug
> important enough to do an initdb for 7.3beta2? I don't have a strong
> feeling either way abou
On Tuesday 03 September 2002 23:47, Christopher Kings-Lynne wrote:
> > I have been doing some poking around with this item, and I was
> > planning on
> > using the stats collector to do "intelligent" auto-vacuuming. I
> > was planning
> > on adding some new columns that account for activity that
On Tuesday 03 September 2002 16:24, Tom Lane wrote:
> "Mario Weilguni" <[EMAIL PROTECTED]> writes:
> > That brings me to another point, can't the
> > statistics collector used for that?
>
> Hmm, that would be a different way of attacking the problem. Not sure
> offhand which is better, but it'd s
> As someone else mentioned (I think), even using a separate schema is not
> always an acceptable option. If you are using a "packaged" application
> (whether commercial or open source), you usually don't want *any*
> changes to the vendor provided database. Particularly with commercial
> software
> > What do people think about this. Is it so bad that the own
> > data is stored in the database pgaccess works with?
>
> pgAdmin II no longer uses such tables, but to get over the problem as
> best I could, I added a cleanup option to pgAdmin I that removed all
> server side objects in one go.
