>> I need to create installation for dumb users to ship DBMS with my
>> application.
>> So manual initial tuning is not possible.
>>
>
> Some tuning is... for instance during installation you should run vacuum
> analyze after loading your data in.
My application runs ANALYZE command programmatical
On Wednesday 30 November 2005 12:12, Andrus wrote:
> >> No. autovacuum is turned ON by default in 8.1 XP
> >
> > Hrm, interesting that it's different than on Unix.
>
> Why major functionality is configured differently in different platforms ?
> This increases the cost of initial tuning when mixed p
>> No. autovacuum is turned ON by default in 8.1 XP
> Hrm, interesting that it's different than on Unix.
Why major functionality is configured differently in different platforms ?
This increases the cost of initial tuning when mixed platforms are used.
> Initial tuning != maintenance. Many of Pos
On Wed, Nov 23, 2005 at 04:56:58PM +0200, Andrus wrote:
> No. autovacuum is turned ON by default in 8.1 XP
Hrm, interesting that it's different than on Unix.
> I read from the docs you mentioned that Postgres has low maintenance needs
> compared to other databases. So I'm expecting that there is
> FWIW, people generally refer to that as 'loading data'; I've never heard
> of 'upsizing' before, which is why I was somewhat confused.
I'm sorry.
I defined upsizing as creating new postgres database from some other
database data.
Google search for upsize returns the titles :
Upsize your Acces
> I agree that the "processing database" message isn't too exciting, but
> it seems that forcing per-table messages up to LOG level would create
> even more log clutter. I could support "processing table" at level
> DEBUG1 and "processing database" at DEBUG2. Or maybe we should think
> harder abo
"Matthew T. O'Connor" writes:
>> LOG: autovacuum: processing database "foo"
> Also this creates a lot of noise in the log files. I think it would be
> better to downgrade this message to a NOTICE or even a DEBUG, and
> replace it with a LOG level message that states when action has taken
> p
Andrus wrote:
Jim,
Keep in mind that if analyze has never been run on a table the database
will assume 1000 rows, which is definately off from 122 rows.
autovacuum processes this tabele regularly.
I believed that autovacuum can update the row count to be real.
I think this is a poor
On Tue, Nov 22, 2005 at 09:33:34PM +0200, Andrus wrote:
> Jim,
>
> > Upsizes? Are you adding more data? If so then yes, analyze would be
> > good, though autovacuum should handle it for you.
>
> I create new Postgres database, upsize a lot of data into it. After that
FWIW, people generally refe
Jim,
> Upsizes? Are you adding more data? If so then yes, analyze would be
> good, though autovacuum should handle it for you.
I create new Postgres database, upsize a lot of data into it. After that
this database goes online and will receive a lot of transactions daily.
I'm using PG 8.1 default
On Tue, Nov 22, 2005 at 09:01:25PM +0200, Andrus wrote:
> Jim,
>
> > Keep in mind that if analyze has never been run on a table the database
> > will assume 1000 rows, which is definately off from 122 rows.
>
> autovacuum processes this tabele regularly.
> I believed that autovacuum can update th
Jim,
> Keep in mind that if analyze has never been run on a table the database
> will assume 1000 rows, which is definately off from 122 rows.
autovacuum processes this tabele regularly.
I believed that autovacuum can update the row count to be real.
> You might want to ask on the pgAdmin list.
Keep in mind that if analyze has never been run on a table the database
will assume 1000 rows, which is definately off from 122 rows.
You might want to ask on the pgAdmin list. Though I'd recommend against
calling the guru 'stupid' over there. :)
On Sun, Nov 20, 2005 at 09:13:36PM +0200, Andrus M
13 matches
Mail list logo
