Skip site navigation (1) Skip section navigation (2)

Re: I/O on select count(*)

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: I/O on select count(*)
Date: 2008-05-15 15:17:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Thu, 15 May 2008, Heikki Linnakangas wrote:
> There's not much point optimizing something that only helps with aborted 
> transactions.

That's fair enough, but this list method is likely to speed up index 
writes anyway.

> The general problem with any idea that involves keeping a list of changes 
> made in a transaction is that that list will grow big during bulk loads, so 
> you'll have to overflow to disk or abandon the list approach. Which means 
> that it won't help with bulk loads.

Yeah, it wouldn't be a list of changes for the transaction, it would be a 
list of changes since the last checkpoint. Keeping data in memory for the 
length of the transaction is doomed to failure, because there is no bound 
on its size, so bulk loads are still going to miss out on hint 


for a in past present future; do
  for b in clients employers associates relatives neighbours pets; do
  echo "The opinions here in no way reflect the opinions of my $a $b."
done; done

In response to

pgsql-performance by date

Next:From: Matthew WakelingDate: 2008-05-15 15:21:24
Subject: Re: which ext3 fs type should I use for postgresql
Previous:From: Heikki LinnakangasDate: 2008-05-15 15:15:50
Subject: Re: I/O on select count(*)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group