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: Pine.LNX.4.64.0805151614330.16756@aragorn.flymine.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
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

In response to

Browse pgsql-performance by date

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