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
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(*) |