Re: Bugs/slowness inserting and indexing cubes
От | Jay Levitt |
---|---|
Тема | Re: Bugs/slowness inserting and indexing cubes |
Дата | |
Msg-id | 4F397451.9070409@gmail.com обсуждение исходный текст |
Ответ на | Re: Bugs/slowness inserting and indexing cubes (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas wrote: > On Mon, Feb 13, 2012 at 7:45 AM, Robert Haas<robertmhaas@gmail.com> wrote: >> On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt<jay.levitt@gmail.com> wrote: >>> So my pre-built 9.1.2 takes 434s, my source-built 9.2 takes 509s, and >>> (probably both of our) 9.1-HEAD takes 1918s... is that something to worry >>> about, and if so, are there any tests I can run to assist? That bug doesn't >>> affect me personally, but y'know, community and all that. Also, I wonder if >>> it's something like "9.2 got way faster doing X, but meanwhile, HEAD got way >>> slower doing Y.", and this is a canary in the coal mine. >> This might be a lame hypothesis, but... is it possible that you built >> your 9.1-tip binaries with --enable-cassert? Or with different >> optimization options? No, I think I/O just varies more than my repeated tests on 1M rows indicated. I ran the 10M-row test four times on the same server, alternating between packaged 9.1.2 and source-built 9.1.2 (default configure options), and saw these times: INSERT INDEX apt 76 578 source 163 636 apt 73 546 source 80 473 EBS has no performance guarantees at all; you share your disks with an arbitrary number of other users, so if someone "in the neighborhood" decides to do some heavy disk I/O, you lose. Let this be a lesson to me: run benchmarks locally! > So I tested. On my MacBook Pro, your test script builds the index in > just over 25 s on both REL9_1_2 and this morning's REL9_1_STABLE. I think that's the 1-million version I emailed; try adding a zero and see if it doesn't take a little longer. Jay
В списке pgsql-hackers по дате отправления: