Having a doubt, we want to vacuum and reindex some 50 most used tables
daily on specific time. Is it best to have a function in postgres and call
it in cron or is there any other good way to do the two process for
specified tables at specified time?
-Arvind S
*
**"Many of lifes failure are people
it was all vacuum full...thanks
the other 2 servers truncate and reload that table from time to time
... IE: they are always vacuumed
as the "master" ... that server never does it... hence the bloat
but why wasn't autovac enough to reclaim at least *most* of the space?
that table *does* get up
Craig Ringer writes:
> Tom Lane wrote:
>> I'm betting on varying degrees of table bloat. Have you tried vacuum
>> full, cluster, etc?
> Or, if you have been using VACUUM FULL, try REINDEXing the tables,
> because it could easily be index bloat. Clustering the table will take
> care of index bloa
Tom Lane wrote:
> Erik Aronesty writes:
>> I have 3 servers, all with identical databases, and each performing
>> very differently for the same queries.
>
> I'm betting on varying degrees of table bloat. Have you tried vacuum
> full, cluster, etc?
Or, if you have been using VACUUM FULL, try REI
Brian Cox writes:
> OK. You mentioned strace. It's got a lot of options; any in particular
> that would be useful if this happens again?
Oh, and don't forget the more-complete pg_locks state. We'll want all
the columns of pg_locks, not just the ones you showed before.
r
Brian Cox writes:
> OK. You mentioned strace. It's got a lot of options; any in particular
> that would be useful if this happens again?
I'd just do "strace -p processID" and watch it for a little while.
If it's not hung, you'll see the process issuing kernel calls at
some rate or other.
If it
Tom Lane [...@sss.pgh.pa.us] wrote:
No, no, and no. What would be best is to find out what actually
happened. The evidence is gone now, but if you see it again please
take a closer look.
OK. You mentioned strace. It's got a lot of options; any in particular
that would be useful if this happens
Brian Cox writes:
> Dp you think it would be better to manually
> vacuum these tables? If so, would it be best to disable autovacuum of
> them? And while I'm at it, if you disable autovacuum of the master table
> will that disable it for the actual partitions?
No, no, and no. What would be be
Tom Lane [...@sss.pgh.pa.us] wrote:
They might have been blocked behind some other process that was sitting
in an open transaction for some reason. The other likely cause is badly
chosen autovacuum delay, but I think that was already covered.
Well, after I noticed this running for a while, I shu
Brian Cox writes:
> Tom Lane [...@sss.pgh.pa.us] wrote:
>> Are those processes actually doing anything, or just waiting? strace
>> or local equivalent would be the most conclusive check.
> These must not have been hung, because they finally completed (after
> 10-15 hrs - some time between 11pm
Tom Lane [...@sss.pgh.pa.us] wrote:
Are those processes actually doing anything, or just waiting? strace
or local equivalent would be the most conclusive check.
These must not have been hung, because they finally completed (after
10-15 hrs - some time between 11pm and 8am). Question is why doe
2009/5/29 Scott Carey
>
> On 5/28/09 6:54 PM, "Greg Smith" wrote:
>
> > 2) You have very new hardware and a very old kernel. Once you've done
> the
> > above, if you're still not happy with performance, at that point you
> > should consider using a newer one. It's fairly simple to build a Linu
Erik Aronesty writes:
> I have 3 servers, all with identical databases, and each performing
> very differently for the same queries.
I'm betting on varying degrees of table bloat. Have you tried vacuum
full, cluster, etc?
regards, tom lane
--
Sent via pgsql-performance
I have 3 servers, all with identical databases, and each performing
very differently for the same queries.
www3 is my fastest, www2 is the worst, and www1 is in the middle...
even though www2 has more ram, faster CPU and faster drives (by far),
and is running a newer version of postgres. I have be
On Sat, May 30, 2009 at 9:41 PM, Greg Smith wrote:
> On Fri, 29 May 2009, Scott Carey wrote:
>
>> There are operations/IT people won't touch Ubuntu etc with a ten foot pole
>> yet for production.
>
> The only thing I was suggesting is that because 2.6.28 is the latest Ubuntu
> kernel, that means i
15 matches
Mail list logo
