Re: I/O on select count(*) - Mailing list pgsql-performance

From Matthew Wakeling
Subject Re: I/O on select count(*)
Date
Msg-id Pine.LNX.4.64.0805151614330.16756@aragorn.flymine.org
Whole thread Raw
In response to Re: I/O on select count(*)  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List 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
optimisation.

Matthew

--
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

pgsql-performance by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: I/O on select count(*)
Next
From: Matthew Wakeling
Date:
Subject: Re: which ext3 fs type should I use for postgresql