Merlin Moncure wrote:
> On 9/20/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
>> Yeah. I'm doing some micro-benchmarking, and the attached test case is
>> much slower with HOT. It's spending a lot of time trying to prune, only
>> to find out that it can't.
>>
>> Instead of/in addition to avoiding pruning when it doesn't help, maybe
>> we could make HeapTupleSatisfiesVacuum cheaper.
>>
>> I'm going to continue testing, this is just a heads-up that HOT as
>> committed seriously hurts performance in some cases. (though one can
>> argue that this test case isn't a very realistic one.)
>
> well, I ran your test on my box and here are the results:
> pre hot:
> run 1: 3617.641 ms
> run 2: 5195.215 ms
> run 3: 6760.449 ms
> after vacuum:
> run 1: 4171.362 ms
> run 2: 5513.317 ms
> run 3: 6884.125 ms
> post hot:
> run 1: Time: 7286.292 ms
> run 2: Time: 7477.089 ms
> run 3: Time: 7701.229 ms
>
> those results aren't exactly terrible,
Your runtimes seem to be increasing as you repeat the test. Did you
remove the "DROP TABLE" from the beginning? On my laptop, post hot takes
~2x as long as pre hot, even when repeated, which matches the results of
your first runs.
> and this case is highly artificial.
Yeah.
I'm going through a bunch of CPU test cases a colleague of mine wrote.
Some of the test cases shows much worse performance with HOT.
Unfortunately they're quite complex and overlapping, so instead of
posting them as is, I'm going through the ones that HOT performs badly
at, and try to reduce them to simpler test cases like the above.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com