On Sat, Aug 21, 2010 at 9:49 AM, Alexandre de Arruda Paes
adald...@gmail.com wrote:
Only for discussion: the CLUSTER command, in my little knowledge, is a
intrusive command that's cannot recover the dead tuples too.
Only TRUNCATE can do this job, but obviously is not applicable all the time.
The problem here is that we're trying to keep an image of a whole
world for any transaction which is in most cases will need to get a
look on few streets around.. ;-)
I understand well that it's respecting the standard and so on, but the
background problem that you may see your table bloated just
Alexandre de Arruda Paes wrote:
Unfortunately, the customer can't wait for the solution and the
programmer eliminated the
use of this table by using a in-memory array.
Well that will be fun. Now they've traded their old problem for a new
one--cache inconsistency between the data in memory
So, does it mean that VACUUM will never clean dead rows if you have a
non-stop transactional activity in your PG database???... (24/7 OLTP
for ex.)
Rgds,
-Dimitri
On 8/19/10, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Alexandre de Arruda Paes adald...@gmail.com wrote:
2010/8/18 Tom
No, it means it can't clean rows that are younger than the oldest
transaction currently in progress. if you started a transaction 5
hours ago, then all the dead tuples created in the last 5 hours are
not recoverable. Dead tuples created before that transaction are
recoverable. If you run
Great! - it's what I expected until now :-)
but discussion in this thread put my mind in trouble :-))
So, the advice for Alexandre here is just to check the age of the
oldest running transaction and the last time when the table in
question was modified.. - if modification time is older than the
2010/8/21 Dimitri dimitrik...@gmail.com
Great! - it's what I expected until now :-)
but discussion in this thread put my mind in trouble :-))
So, the advice for Alexandre here is just to check the age of the
oldest running transaction and the last time when the table in
question was
Alexandre de Arruda Paes adald...@gmail.com wrote:
2010/8/18 Tom Lane t...@sss.pgh.pa.us
There's an open transaction somewhere that VACUUM is preserving
the tuples for. This transaction need not ever have touched the
table, or ever intend to touch the table --- but VACUUM cannot
know that,
Alexandre de Arruda Paes adald...@gmail.com writes:
Below, the pg_prepared_xacts result.
OK, so you don't have any prepared transactions, but you're still not
showing us the full content of pg_stat_activity.
Just out of curiosity, how many rows does select count(*) from tp93t
think there are?
I'm forwarding again this email to list, because Me and Scoot unfortunately
was talking alone. (thanks Scott)
So what do:
select * from pg_stat_activity where current_query ilike '%transaction%';
and
select * from pg_stat_activity where now()-current_query '1
minute'::interval;
say?
You should
Alexandre de Arruda Paes adald...@gmail.com writes:
I know the problem with VACUUM FULL and bloated Indexes, but I don't
understand why the table that is not in use by nobody, cant be vacuumed or
clustered to avoid dead tuples.
There's an open transaction somewhere that VACUUM is preserving
11 matches
Mail list logo
