Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> And two, that upper plan nodes seem much more affected than lower
>> ones. That makes sense because the execution cycle of an upper node
>> will involve touching more userspace data than a lower node, and
>> therefore more of the flushed TLB entries will need to be reloaded.
> I would have expected the opposite effect. If you only execute one instruction
> then the cache miss can make it take many times longer than normal. But as the
> number of instructions grows the cache gets repopulated and the overhead
> levels off and becomes negligible relative to the total time.
Well, none of our plan nodes are in the "one instruction" regime ;-).
I was thinking that the total volume of data accessed was the critical
factor. Right at the moment I'm disillusioned with the TLB-access
theory though.
Something I'm noticing right now is that it seems like only hash joins
are really seriously misestimated --- nest and merge joins have some
small issues but only the hash is way out there. What's going on??
Can anyone else reproduce this?
> The other option aside from gprof-like profiling would be to
> investigate those cpu timing instructions again. I know some of them
> are unsafe on multi-cpu systems but surely there's a solution out
> there. It's not like there aren't a million games, music playing, and
> other kewl kid toys that depend on accurate low overhead timing these
> days.
Yeah, and they all work only on Windoze and Intel chips :-(
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
