Tom Lane wrote:
What this means is that if we start with "next" pointing at a page
without enough space (quite likely considering that we now index all
pages not only those with free space), then it is highly possible that
the search will end on a page *before* where next was. The most trivial
c
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test was
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> Second idea is that new FSM creates heavy defragmented data and index
>> scan needs to jump from one page to another too often.
> Hmm. That's remotely plausible, I suppose. The old FSM only kept track
> of pages with more t
Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test was surprise for me. I run
origin
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test was surprise for me. I run original
server (with old FS
Heikki Linnakangas napsal(a):
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call FreeSpaceM
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One thing that jumped out at me is that you call FreeSpaceMapExtendRel
>> every time a rel is extended by even one block.
> Yes, most of those calls end up being no-op. Which is exactly why I
> would be surprised if those made an
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call FreeSpaceMapExtendRel
every time a rel is
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> My conclusion is that new implementation is about 8% slower in OLTP
>> workload.
> Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call FreeSpaceMapExtendRel
every time a rel is extended by
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I'll try something but I do not guarantee result.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
Looks like I need to blow the dust off my DBT-2 test rig and try to
reproduce that as well.
--
Heikki Linnakangas
EnterpriseDB http://www.enterpr
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Hi Heikki,
I finally performed iGen test. I used two v490 servers with 4 dual core SPARC
CPUs and 32GB RAM. I have only one disk and I did not performed any disk I/O
optimization. I tested 105 parallel connection and think time was 200ms.
See the result:
Original:
-
Actual run/snap-sh
13 matches
Mail list logo
