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, and this case is highly artificial.
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.
Yeah, it's highly artificial.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
