On Wed, Aug 15, 2012 at 11:30 PM, J Ramesh Kumar wrote:
>
> Hi David Barton,
>
> Please find the information below.
>
>> Are you able to provide a table schema?
>
>
> There are 109 different types of table. I am maintaining some tables are
> daily tables and some tables are ID based. So totally we
Thanks Kevin.
Postgres version is 9.1.4 (lastest)
Every day the table has about 7 millions of new rows.
The table hold the data for 60 days, so approx. the total rows must be
around 420 millions.
Every night a delete process run, and remove rows older than 60 days.
So, the space used by postgres
[please don't top-post]
"Anibal David Acosta" wrote:
> Kevin Grittner wrote:
>> "Anibal David Acosta" wrote:
>>
>>> if I have a table that daily at night is deleted about 8
>>> millions of rows (table maybe has 9 millions) is recommended to
>>> do a vacuum analyze after delete completes or ca
"Anibal David Acosta" wrote:
> if I have a table that daily at night is deleted about 8 millions
> of rows (table maybe has 9 millions) is recommended to do a vacuum
> analyze after delete completes or can I leave this job to
> autovacuum?
Deleting a high percentage of the rows should cause au
On 08/16/2012 04:33 PM, Anibal David Acosta wrote:
Hi,
if I have a table that daily at night is deleted about 8 millions of
rows (table maybe has 9 millions) is recommended to do a vacuum
analyze after delete completes or can I leave this job to autovacuum?
This table is very active during
Hi,
if I have a table that daily at night is deleted about 8 millions of rows
(table maybe has 9 millions) is recommended to do a vacuum analyze after
delete completes or can I leave this job to autovacuum?
This table is very active during the day but less active during night
I think that
Thanks for the help everyone and sorry for not replying sooner, I was on
a business trip.
@Hubert pg_reorg looks really interesting and from the first read it looks
to be a very good solution for maintenance, but for now I would rather try
to slow down, or remove this bloat, so I have to do as les
On Wed, Aug 15, 2012 at 6:43 AM, Doug Hunley wrote:
> On Tue, Aug 14, 2012 at 1:29 PM, k...@rice.edu wrote:
>>
>> It probably has to do with the fact that a conditional index, does
>> not include every possible row in the table. Although, a "cluster" of
>> the matching rows and then leave the res
delongboy wrote:
> We are not doing anything to postgres that would cause the rise
> and drop. Data base activity is pretty consistent. nor are we
> doing any kind of purge. This week the drop occurred after 6
> days. We are thinking it must be some kind of internal postgres
> activity but we
We are not doing anything to postgres that would cause the rise and drop.
Data base activity is pretty consistent. nor are we doing any kind of
purge. This week the drop occurred after 6 days. We are thinking it must
be some kind of internal postgres activity but we can't track it down.
--
V
On Thu, Aug 16, 2012 at 06:07:26PM +0200, anara...@anarazel.de wrote:
>
>
> Bruce Momjian schrieb:
>
> >On Thu, Aug 16, 2012 at 03:48:57PM +1000, Ondrej Ivanič wrote:
> >> Hi,
> >>
> >> On 16 August 2012 15:40, J Ramesh Kumar
> >wrote:
> >> > As you said, MySQL with MyISAM is better choice fo
On Wed, Aug 15, 2012 at 2:19 PM, Bosco Rama wrote:
> On 08/15/12 14:05, Josh Berkus wrote:
>>
>>> That actually makes sense to me. Cluster the rows covered by that
>>> index, let the rest fall where they may. I'm typically only accessing
>>> the rows covered by that index, so I'd get the benefit o
Bruce Momjian schrieb:
>On Thu, Aug 16, 2012 at 03:48:57PM +1000, Ondrej Ivanič wrote:
>> Hi,
>>
>> On 16 August 2012 15:40, J Ramesh Kumar
>wrote:
>> > As you said, MySQL with MyISAM is better choice for my app. Because
>I don't
>> > need transaction/backup. May be I'll try with InnoDB and f
On Wed, Aug 15, 2012 at 5:19 PM, Bosco Rama wrote:
> On 08/15/12 14:05, Josh Berkus wrote:
>>
>>> That actually makes sense to me. Cluster the rows covered by that
>>> index, let the rest fall where they may. I'm typically only accessing
>>> the rows covered by that index, so I'd get the benefit o
On Wed, Aug 15, 2012 at 11:40 PM, J Ramesh Kumar wrote:
> Dear Scott Marlowe,
>
> Thanks for the details.
>
> As you said, MySQL with MyISAM is better choice for my app. Because I don't
> need transaction/backup.
That's not exactly what I said. Remember that if you need to run
complex queries po
On Thu, Aug 16, 2012 at 10:53:21AM -0400, Bruce Momjian wrote:
> On Thu, Aug 16, 2012 at 03:48:57PM +1000, Ondrej Ivanič wrote:
> > Hi,
> >
> > On 16 August 2012 15:40, J Ramesh Kumar wrote:
> > > As you said, MySQL with MyISAM is better choice for my app. Because I
> > > don't
> > > need transa
On Thu, Aug 16, 2012 at 03:48:57PM +1000, Ondrej Ivanič wrote:
> Hi,
>
> On 16 August 2012 15:40, J Ramesh Kumar wrote:
> > As you said, MySQL with MyISAM is better choice for my app. Because I don't
> > need transaction/backup. May be I'll try with InnoDB and find the disk
> > write/space differ
17 matches
Mail list logo
