Re: VACUUM warning message.

Поиск
Список
Период
Сортировка
От
Тема Re: VACUUM warning message.
Дата
Msg-id 1057.219.65.252.149.1043723597.squirrel@mail.trade-india.com
обсуждение исходный текст
Ответ на Re: VACUUM warning message.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: VACUUM warning message.
Список pgsql-admin

Hmm i do the below daily to this table. And this is pgsql 7.3

~~~~~~~~~~~~~~~~~~~~~~~
BEGIN WORK;
INSERT INTO archives.site_search SELECT * from public.site_search;
COMMIT;
TRUNCATE TABLE public.site_search;
~~~~~~~~~~~~~~~~~~~~~~
and then it is VACUMMED within 24 hrs.

The table public.site_search only under goes INSERTS thruout the day and
no updates and archives.site_search only undergoes a bulk insert once in 24 hrs
and "SELECTS" most of the time.

public.site_search starts from 0 records and ends up to 4000-5000 records
before the truncate.

archives.site_search contains 6,50,000 apprx.

Related Problem [ OT ] : this approach was taken because i was getting
very poor performance when i was inserting and reading data from the same
table within a transaction. only one table used to exists containg apprx
 .6  million records. I feel there was some kind of locking going on
 using this approach inserts and reads are from different table and
perforamance is much better.

Regds
Mallah.


> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I assume this is 7.2.X.  I know this is fixed in 7.3.1 but I am not sure what release we fixed
>> it in.  The HISTORY file doesn't have a specific mention of the fix.  It is not something to
>> be worried about, as I remember.
>
> Mmm, I'm not sure.  The known variant of this problem only affects certain system tables (the
> nailed-in-cache ones):
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00486.php
>
> This is evidently a user table:
>
>> WARNING:  Rel site_search: Uninitialized page 1 - fixing
>
> I'd wonder about hardware failures, myself.  Does the table appear to have lost a lot of rows
> that should have been there?
>
> Other interesting questions are whether the table has recently undergone a TRUNCATE, or
> deletion of a large fraction of its rows followed by VACUUM (probably VACUUM FULL).
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)--------------------------- TIP 6: Have you
> searched our list archives?
>
> http://archives.postgresql.org



-----------------------------------------
Get your free web based email at trade-india.com.
   "India's Leading B2B eMarketplace.!"
http://www.trade-india.com/



В списке pgsql-admin по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: Replication
Следующее
От: Carwyn Edwards
Дата:
Сообщение: Python DB-API problem with PostgresSQL pgdb.