Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-09-07 at 22:08 -0400, Bruce Momjian wrote:
I don't see how following a HOT chain is any slower than following an
UPDATE chain like we do now.
The speed/cost is the same. The issue is *when* we do this. Normal
SELECTs will follow the chain
Tom Lane wrote:
Compared to what it currently takes to check the same tuple (a separate
index entry fetch and traversal to the heap page), this is already an
enormous performance improvement.
Though keep in mind that we kill index tuples as soon as they're deemed
to be dead. Nevertheless, I'm
Heikki Linnakangas wrote:
Tom Lane wrote:
Compared to what it currently takes to check the same tuple (a separate
index entry fetch and traversal to the heap page), this is already an
enormous performance improvement.
Though keep in mind that we kill index tuples as soon as they're deemed
to
Florian Pflug wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Compared to what it currently takes to check the same tuple (a separate
index entry fetch and traversal to the heap page), this is already an
enormous performance improvement.
Though keep in mind that we kill index tuples as
On Sat, 2007-09-08 at 17:46 +0100, Heikki Linnakangas wrote:
Tom Lane wrote:
Compared to what it currently takes to check the same tuple (a separate
index entry fetch and traversal to the heap page), this is already an
enormous performance improvement.
Though keep in mind that we kill
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom argued that following the tuple chain is cheap enough, and might
even be cheaper than what we have now, that we don't need to prune just
for the purpose of keeping the chains short. To which I pointed out that
currently, without HOT, we mark
Heikki Linnakangas wrote:
Florian Pflug wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Compared to what it currently takes to check the same tuple (a separate
index entry fetch and traversal to the heap page), this is already an
enormous performance improvement.
Though keep in mind that we
Tom Lane wrote:
This patch implements Florian's idea about how to manage snapshot xmax
without the ugly and performance-losing tactic of taking XidGenLock and
ProcArrayLock at the same time. I had to do a couple of slightly klugy
things to get bootstrap and prepared transactions to work, but on
Simon Riggs wrote:
If we defer pruning until the page is full, worst case we may could end
up with a chain ~240 tuples long, which might need to be scanned
repeatedly. That won't happen often, but it would be better to prune
whenever we hit one of these conditions
- when the block
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Florian Pflug wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Compared to what it currently takes to check the same tuple (a separate
index entry fetch and traversal to the heap page), this is already an
enormous performance improvement.
Florian Pflug [EMAIL PROTECTED] writes:
I was under the impression that pruning *does* free the space occupied
by DEAD HOT-Tuples (minus the size of a redirection line pointer). It
just doesn't defragment, so how much of that freed space you can actually
use to store new tuples is another
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
The speed/cost is the same. The issue is *when* we do this. Normal
SELECTs will follow the chain each time we do an index lookup.
But a sequential scan still follows the chain, and that isn't going to
prune. Why are we more worried
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom argued that following the tuple chain is cheap enough, and might
even be cheaper than what we have now, that we don't need to prune just
for the purpose of keeping the chains short. To which I pointed out that
currently,
13 matches
Mail list logo
