Professional Web Applications Themes

UDB EEE Partitioning and Standard Insert Performance - IBM DB2

We are attempting to insert 12 Million rows via a single threaded application issuing vanilla insert statements into a 7.2 EEE database with 8 nodes. Would it make sense that if you had a table partitioned across 2 nodes vs 8 nodes you would see a 75% drop in performance when doing single threaded standard inserts via odbc to the controling node? My logic is with 2 nodes you ship 1/2 your data whereas 4 nodes 3/4 and 8 nodes 7/8. It appears to have significant impacts on our performance as the more data we have to ship seems to ...

  1. #1

    Default UDB EEE Partitioning and Standard Insert Performance


    We are attempting to insert 12 Million rows via a single threaded
    application issuing vanilla insert statements into a 7.2 EEE database
    with 8 nodes.

    Would it make sense that if you had a table partitioned across 2 nodes
    vs 8 nodes you would see a 75% drop in performance when doing single
    threaded standard inserts via odbc to the controling node? My logic is
    with 2 nodes you ship 1/2 your data whereas 4 nodes 3/4 and 8 nodes 7/8.
    It appears to have significant impacts on our performance as the more
    data we have to ship seems to incure a large performance hit.

    Our tests show that with 2 nodes we see 500 Rows/Sec, 4 nodes we see 250
    Rows/Sec and 8 nodes 125 Rows/Sec. It seems to increase linearly with
    the number of nodes. Why would this be? The interconnect between the
    nodes should be super fast and should not be the cause of perf
    degredation in my opinion but evidence seems to prove otherwise.

    Please don't tell me to use the autoloader, import or buffered inserts.
    DB2 should not incur a perf hit for a standard insert with each node
    added and I want to know why it appears that way.

    Thoughts? Comments?

    Spencer

    --
    Posted via [url]http://dbforums.com[/url]
    stabbert Guest

  2. #2

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    "stabbert" <member31496dbforums.com> wrote in message
    news:3072676.1057254458dbforums.com...
    >
    > We are attempting to insert 12 Million rows via a single threaded
    > application issuing vanilla insert statements into a 7.2 EEE database
    > with 8 nodes.
    >
    > Would it make sense that if you had a table partitioned across 2 nodes
    > vs 8 nodes you would see a 75% drop in performance when doing single
    > threaded standard inserts via odbc to the controling node? My logic is
    > with 2 nodes you ship 1/2 your data whereas 4 nodes 3/4 and 8 nodes 7/8.
    > It appears to have significant impacts on our performance as the more
    > data we have to ship seems to incure a large performance hit.
    >
    > Our tests show that with 2 nodes we see 500 Rows/Sec, 4 nodes we see 250
    > Rows/Sec and 8 nodes 125 Rows/Sec. It seems to increase linearly with
    > the number of nodes. Why would this be? The interconnect between the
    > nodes should be super fast and should not be the cause of perf
    > degredation in my opinion but evidence seems to prove otherwise.
    >
    > Please don't tell me to use the autoloader, import or buffered inserts.
    > DB2 should not incur a perf hit for a standard insert with each node
    > added and I want to know why it appears that way.
    >
    > Thoughts? Comments?
    >
    > Spencer
    >
    What is the interconnect between nodes?


    Mark A Guest

  3. #3

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    stabbert <member31496dbforums.com> wrote in message news:<3072676.1057254458dbforums.com>...
    > Our tests show that with 2 nodes we see [row insertion rates of] 500
    > Rows/Sec, 4 nodes we see 250 Rows/Sec and 8 nodes 125 Rows/Sec.
    > It seems to increase linearly with the number of nodes. Why would this be?
    Seems almost a bit too linear. If it's not too obvious a question,
    you are measuring the overall throughput, not throughput on a single
    node?


    Jeremy
    Jeremy Rickard Guest

  4. #4

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    Can you define what a "vanilla insert" is? I.e. single row values with
    constants? Parameter markers a subselect?
    As stated by others your numbers seem too linear. You reasoning as such
    holds. There is a cost to ship the data to the correct node. But
    everytime you add a node only a fraction more of the rows inserted will
    now go to a remore node rather than being local.
    The cost for all other nodes is constants. So you would expect an
    asymtotic drop of performance on the insert limited by inserting ALL
    rows into remote nodes.

    Cheers
    Serge

    --
    Serge Rielau
    DB2 UDB SQL Compiler Development
    IBM Software Lab, Toronto

    Visit DB2 Developer Domain at
    [url]http://www7b.software.ibm.com/dmdd/[/url]


    Serge Rielau Guest

  5. #5

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    Hi,

    How well is your data partitioning?

    - i.e what key are you partitioned on and what is its uniqueness?

    Maybe some of skew is occuring ?
    Paul Reddin Guest

  6. #6

    Default Re: UDB EEE Partitioning and Standard Insert Performance


    "Paul Reddin" <paulabacus.co.uk> wrote in message
    news:1fd2a603.0307040758.430f29cdposting.google.c om...
    > Hi,
    >
    > How well is your data partitioning?
    >
    > - i.e what key are you partitioned on and what is its uniqueness?
    >
    > Maybe some of skew is occuring ?
    There is no benefit of using a parallel database configuration if doing
    multiple simple inserts (non-buffered) . To exploit parallel processing with
    inserts, buffered inserts or other techniques are required.

    If a single program was used to select one row 5 million times (using a
    predicate that matches a unique index), it would not benefit from parallel
    processing. The extra overhead of communicating (2 ways) between the
    partitions and the nodes would make performance worse than if a non-parallel
    database was used. Not all SQL statements or scenarios can exploit parallel
    processing.

    The good news is that for significant insert activity, buffered inserts will
    enable significant performance gains that exploits parallel database
    technology.


    Mark A Guest

  7. #7

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    "stabbert" <member31496dbforums.com> wrote in message
    news:3076967.1057369851dbforums.com...
    >
    > To answer some of the questions:
    >
    > I believe the interconnect to be a Gigabit connection between each node.
    >
    > We are partitioning on the primary key which is a unique single column
    > integer value.
    >
    > Ok the numbers weren't exactly 500, 250, 125 for inserts but darn close.
    > I probably should of said this so sorry I didn't.
    >
    > I define a vanilla insert as a single row insert with values supplied as
    > a constant.
    >
    > We also ran some additional tests which showed some interesting results.
    > The first was partitioning a table across only two of the eight nodes
    > with one being the controlling node. We expected perf of this test to
    > equal our development box which is a 2 node box. While we saw some perf
    > increase(ie. 125 rows up to 180 rows) it was not the expected ~500
    > rows/sec we saw in production. So it seems either our prod box is out
    > of wack or there is additional overhead of partitioning with each node
    > added whether the table is partitioned across it.
    >
    > The last test proved to be the most interesting by far. We created the
    > table in a unpartitioned space on the controlling node in development(2
    > nodes) and production(8 nodes). Performance was 3500 - 4000 rows/sec
    > regardless of running in production or development. Far exceeding our
    > expectations.
    >
    > This just doesn't seem right. I have to imagine that some very large
    > OLTP type applications that do many "vanilla inserts"(as defined by me
    > above) are using EEE. This is not acceptable performance at all. What
    > else can we look at??
    >
    > Spencer

    Parallel database was invented (by Teradata) for use in long running queries
    on very large tables where the number of rows processed is quite large. IBM
    and others have made great strides in getting parallelism to work with OLTP
    with the use of buffered inserts and other techniques in that can be used in
    certain situations. But parallel technology simply does not improve
    performance in every situation.

    Parallel database technology does not help on "vanilla inserts" all coming
    from the same application thread. In fact, the overhead of the additional
    nodes is worse than a single node non-partitioned database. If you want to
    exploit parallel technology when inserting, use buffered inserts.

    If you have a large OLTP application and you need parallelism, and cannot
    use buffered inserts, you probably need multi-node application servers and
    not a multi-node parallel database. You may need to get a better
    understanding of what parallel architecture (application parallelism or
    database parallelism) can do for you and how to exploit it.


    Mark A Guest

  8. #8

    Default Re: UDB EEE Partitioning and Standard Insert Performance


    It absolutely makes sense about what is being said in regards to EEE
    and insert performance. It makes sense that there would be some
    performance degredation because of the additional overhead to ship data
    to the other nodes. However, I still am extremely disapointed by the
    perf DB2 is giving us. I mean the perf we are seeing is terrible in my
    mind. Comparing the test done with a unpartitioned table on the
    controlling node getting 4,000 rows/sec to a table partitioned across 2
    nodes yielding 180 - 500 rows/sec is terrible. While you should see
    some perf implications it shouldn't be 1000% - 2000% slower.

    I was able to dig up an article showing some interesting stats in
    regards to using buffered vs non buffered inserts. This test is fairly
    similar to what our application does in theory. Interesting to see they
    were not able to achieve over 200 rows/sec without using buffered
    inserts and then when using buffered inserts achieve over 1000 rows/sec.
    [url]http://www7b.boulder.ibm.com/dmdd/library/techarticle/0204pooloth/0204p-[/url]
    ooloth.html

    Spencer

    --
    Posted via [url]http://dbforums.com[/url]
    stabbert Guest

  9. #9

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    "stabbert" <member31496dbforums.com> wrote in message
    news:3077472.1057407217dbforums.com...
    >
    > It absolutely makes sense about what is being said in regards to EEE
    > and insert performance. It makes sense that there would be some
    > performance degredation because of the additional overhead to ship data
    > to the other nodes. However, I still am extremely disapointed by the
    > perf DB2 is giving us. I mean the perf we are seeing is terrible in my
    > mind. Comparing the test done with a unpartitioned table on the
    > controlling node getting 4,000 rows/sec to a table partitioned across 2
    > nodes yielding 180 - 500 rows/sec is terrible. While you should see
    > some perf implications it shouldn't be 1000% - 2000% slower.
    >
    I don't understand why you say "it shouldn't". Parallel database technology
    is not design for sequential inserting.


    Mark A Guest

  10. #10

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    >>>>> "Spencer" == stabbert <member31496dbforums.com> writes:

    Spencer> nodes. However, I still am extremely disapointed by the
    Spencer> perf DB2 is giving us. I mean the perf we are seeing is
    Spencer> terrible in my mind. Comparing the test done with a
    Spencer> unpartitioned table on the controlling node getting 4,000
    Spencer> rows/sec to a table partitioned across 2 nodes yielding
    Spencer> 180 - 500 rows/sec is terrible. While you should see
    Spencer> some perf implications it shouldn't be 1000% - 2000%
    Spencer> slower.

    An insert of a single row in a non-partitioned database is a fairly
    simple operation - especially if there is no index.

    When you are running in a parallel plan, you are paying the following
    extra penalties:

    1. Startup costs of initializing a parallel plan - the co-ordinator
    will distribute the plan to the various subordinates and the table
    queues to exchange data will be initialized.

    2. Hashing

    3. 2PC for the distributed transaction. db2 uses the Presumed Abort
    (PA) version of 2PC (like most everybody else). PA does better in the
    case where the workload is read-only as otherwise it has more log
    syncs. The insert of a single row will cause 2PC-PA traffic
    (PREPARE,VOTE-YES,COMMIT) for _every_ row (plus log syncs in _every_
    node).

    4. Teardown costs - the plans on every node will be destroyed.

    Of course the hashing cost is negligible. The other costs however
    could easily add up to much more than the insert of a single row. If
    the bottleneck is in their costs, then what you are really measuring
    is not the insert cost. It is the parallel "overhead". I have to think
    about it some more, but on the face of it I don't see a linear
    increase in overhead as particularly bad (although logarithmic would
    be better :-)

    It gets worse though. Since you are partitioning around a single key,
    for each row being inserted, the nodes apart from the affected
    subordinate and the coordinator are _all_ going to pay the startup and
    destruction costs to no avail. Even if you think that this should not
    affect the response time note that the coordinator is paying an
    unncessary cost of interacting with and initializing queues between an
    unused subordinate.

    [Did Teradata really invent parallel databases ? At the same time
    there was the GAMMA project at the Univ of Wisconsin and BUBBA at MCC,
    not to mention Graefe's Volcano project. Certainly Teradata invented
    interleaved declustering while chained declustering came with Gamma.]

    --
    Pip-pip
    Sailesh
    [url]http://www.cs.berkeley.edu/~sailesh[/url]

    Sailesh Krishnamurthy Guest

  11. #11

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    "Sailesh Krishnamurthy" <seesignaturecs.berkeley.edu> wrote in message
    news:bxyadbsnk10.fsfdatafix.cs.berkeley.edu...
    > [Did Teradata really invent parallel databases ? At the same time
    > there was the GAMMA project at the Univ of Wisconsin and BUBBA at MCC,
    > not to mention Graefe's Volcano project. Certainly Teradata invented
    > interleaved declustering while chained declustering came with Gamma.]
    >
    > --
    > Pip-pip
    > Sailesh
    > [url]http://www.cs.berkeley.edu/~sailesh[/url]
    >
    I would say that Teradata was the first to bring a commercial parallel
    database to the market. As to who invented the concept< I don't know. But
    there is usually a big difference between the concept in a research setting
    and a commercial product with real paying customers.


    Mark A Guest

  12. #12

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    >>>>> "Mark" == Mark A <maswitchboard.net> writes:

    Mark> "Sailesh Krishnamurthy" <seesignaturecs.berkeley.edu> wrote
    >> [Did Teradata really invent parallel databases ? At the same
    >> time there was the GAMMA project at the Univ of Wisconsin and
    >> BUBBA at MCC, not to mention Graefe's Volcano
    >> project. Certainly Teradata invented interleaved declustering
    Mark> I would say that Teradata was the first to bring a
    Mark> commercial parallel database to the market. As to who

    That sounds about right to me - I don't know of any other commercial
    system that had shared nothing support before Teradata. Of course,
    Teradata's market is ytics as opposed to transaction processing.

    Mark> invented the concept< I don't know. But there is usually a
    Mark> big difference between the concept in a research setting and
    Mark> a commercial product with real paying customers.

    I was just trying to make sure credit got to where its due :-)

    I am of course (painfully) aware of the difference between invention
    in academic and industrial settings. While there is certainly a big
    difference there are other things that have come out of the database
    industry without as much academic influence.

    --
    Pip-pip
    Sailesh
    [url]http://www.cs.berkeley.edu/~sailesh[/url]

    Sailesh Krishnamurthy Guest

  13. #13

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    "Sailesh Krishnamurthy" <seesignaturecs.berkeley.edu> wrote in message
    news:bxy1xx3um5o.fsfdatafix.cs.berkeley.edu...
    > That sounds about right to me - I don't know of any other commercial
    > system that had shared nothing support before Teradata. Of course,
    > Teradata's market is ytics as opposed to transaction processing.
    >
    > Mark> invented the concept< I don't know. But there is usually a
    > Mark> big difference between the concept in a research setting and
    > Mark> a commercial product with real paying customers.
    > --
    > Pip-pip
    > Sailesh
    I don't think the first release of DB2 Parallel Edition (as it was called
    back then) was much different than Teradata in its focus on queries rather
    than transaction processing. I know of some companies that have used
    Teradata for transaction processing more recently, but I am not up-to-date
    on how well it compares with DB2 ESE or Oracle Parallel Database in that
    regard.


    Mark A Guest

  14. #14

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    vanilla in software terms generally means :
    original, unmodified software, software with no customer custom code.

    So i guess the intended meaning was :
    plain old insert statement. (not load, not import, no batch insert, ...)

    PM


    PM \(pm3iinc-nospam\) Guest

  15. #15

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    >>>>> "Mark" == Mark A <maswitchboard.net> writes:

    Mark> "Sailesh Krishnamurthy" <seesignaturecs.berkeley.edu> wrote
    Mark> in message news:bxy1xx3um5o.fsfdatafix.cs.berkeley.edu...
    >> That sounds about right to me - I don't know of any other
    >> commercial system that had shared nothing support before
    >> Teradata. Of course, Teradata's market is ytics as opposed
    >> to transaction processing.
    Mark> I don't think the first release of DB2 Parallel Edition (as
    Mark> it was called back then) was much different than Teradata in
    Mark> its focus on queries rather than transaction processing. I

    Oh, I guess it wasn't but now I'm not speaking for IBM - actually I
    rarely am speaking for IBM. Let me amend that - I never speak for IBM,
    and given that IBM never speaks for me that's fine :-)

    In fact, in general I'm curious as to people's experiences with shared
    nothing parallelism in OLTP environments. Certainly the DB2 on Windows
    TPC-C benchmarks show that it's possible to scale well. Still I'm
    curious to learn more about "war stories". Just out of academic
    interest !

    Mark, I'm not opposed to your response to Spencer that a
    shared-nothing cluster database was/is not designed for a large number
    of vanilla insert statements. That said, it's certainly interesting to
    get a handle on why we see some performance results.

    I can understand Spencer's concerns. However, what will now be
    interesting is if he can post a comparison of the insert times he can
    generate with buffered inserts in serial and parallel mode. Then we
    can better test the theory that what he's measuring is parallel
    overhead.

    --
    Pip-pip
    Sailesh
    [url]http://www.cs.berkeley.edu/~sailesh[/url]

    Sailesh Krishnamurthy Guest

  16. #16

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    Would that be in a cup or cone then?
    INSERT INTO t VALUES (?, ?, ?);
    INSERT INTO t VALUES (1, 2, 3);
    INSERT INTO t VALUES (1, 2, 3), (4, 5,6 ), ...
    INSERT INTO t SELECT * FROM S;

    Cheers
    Serge

    --
    Serge Rielau
    DB2 UDB SQL Compiler Development
    IBM Software Lab, Toronto

    Visit DB2 Developer Domain at
    [url]http://www7b.software.ibm.com/dmdd/[/url]


    Serge Rielau Guest

  17. #17

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    I have experience with Informix XPS, the "Teradata on the cheap" MPP
    shared-nothing database from Informix, now owned by IBM. XPS has
    been out since 1996 or maybe even earlier.

    I haven't used XPS in a while although IBM is supposedly supporting
    it. XPS has a high-performance loader that is extremely fast, well
    developed, and does parallel loading very easy. All the loading with
    the XPS high-peformance loader is unbuffered, if my memory serves
    me correctly. On the project I was on with XPS we used to load
    large data sets very fast and easy, on a 4-way IBM SP70 cluster.

    Adding more nodes should decrease the time to load, not increase
    it. I hope what I'm reading in this thread so far is operator error
    or misunderstanding, as I'm investigating whether or not our
    company should be using DB2. I'd rather use XPS but until IBM
    actually markets Informix products I'm not touching them ever
    again.

    By the way, parallel loading IS part of the design of most if not
    all shared nothing MPP systems. If DB2 is missing this feature then
    it is truly lacking. If I were investigating this problem I'd make sure
    any additional flags or settings for parallelism were set for the load,
    I'm guessing it's automagic on DB2, but you'll have to check.

    Tim

    "Mark A" <maswitchboard.net> wrote in message
    news:bJANa.3$Xe5.17487news.uswest.net...
    > "stabbert" <member31496dbforums.com> wrote in message
    > news:3077472.1057407217dbforums.com...
    > >
    > > It absolutely makes sense about what is being said in regards to EEE
    > > and insert performance. It makes sense that there would be some
    > > performance degredation because of the additional overhead to ship data
    > > to the other nodes. However, I still am extremely disapointed by the
    > > perf DB2 is giving us. I mean the perf we are seeing is terrible in my
    > > mind. Comparing the test done with a unpartitioned table on the
    > > controlling node getting 4,000 rows/sec to a table partitioned across 2
    > > nodes yielding 180 - 500 rows/sec is terrible. While you should see
    > > some perf implications it shouldn't be 1000% - 2000% slower.
    > >
    > I don't understand why you say "it shouldn't". Parallel database
    technology
    > is not design for sequential inserting.
    >
    >


    Tim Schaefer Guest

  18. #18

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    >>>>> "Tim" == Tim Schaefer <designdatahotmail.com> writes:

    Tim> I haven't used XPS in a while although IBM is supposedly
    Tim> supporting it. XPS has a high-performance loader that is
    Tim> extremely fast, well developed, and does parallel loading
    Tim> very easy. All the loading with the XPS high-peformance
    Tim> loader is unbuffered, if my memory serves me correctly. On
    Tim> the project I was on with XPS we used to load large data sets
    Tim> very fast and easy, on a 4-way IBM SP70 cluster.

    DB2 has a high-performance load utility that makes parallel loading
    fast as well. The original poster was however deliberately trying a
    very restricted test case - where the client repeatedly issues vanilla
    insert statements of one row each.

    If you read his post you'll see that he says something like "please
    don't tell me about load, import or buffered inserts".

    Tim> By the way, parallel loading IS part of the design of most if
    Tim> not all shared nothing MPP systems. If DB2 is missing this
    Tim> feature then it is truly lacking. If I were investigating
    Tim> this problem I'd make sure any additional flags or settings
    Tim> for parallelism were set for the load, I'm guessing it's
    Tim> automagic on DB2, but you'll have to check.

    Of course. You load the data using the same command you'd use on a
    serial system. I don't know if the autoloader will also exploit SMP
    parallelism.

    --
    Pip-pip
    Sailesh
    [url]http://www.cs.berkeley.edu/~sailesh[/url]

    Sailesh Krishnamurthy Guest

  19. #19

    Default Re: UDB EEE Partitioning and Standard Insert Performance


    I am now begining to understand the complexities of managing an insert
    against a partitioned table across several nodes on an MPP system. I do
    appreciate everyones help in this matter. I would also agree with
    Sailesh and am very curious how OLTP type applications achieve high
    performance in a shared nothing MPP environment. I will post additional
    information as it becomes available through our testing.

    Sailesh, you make reference to partitioning on a single key and the
    startup and destruction cost occuring on every node. Is there a better
    way to partition to avoid this? Is there ways to avoid this startup and
    destruction cost on every node?

    Tim, yes DB2 does support utilities and options to load data to a multi
    node EEE instance in a very high speed manner ie. AutoLoader and Import
    with Buffered Inserts. What this post deals with is achieving high
    performance inserts not using that methodology.

    Spencer

    --
    Posted via [url]http://dbforums.com[/url]
    stabbert Guest

  20. #20

    Default Re: UDB EEE Partitioning and Standard Insert Performance

    "Sailesh Krishnamurthy" <seesignaturecs.berkeley.edu> wrote in message
    news:bxyptkmx05g.fsfdatafix.cs.berkeley.edu...
    > >>>>> "Mark" == Mark A <maswitchboard.net> writes:
    >
    > Mark> "Sailesh Krishnamurthy" <seesignaturecs.berkeley.edu> wrote
    > Mark> in message news:bxy1xx3um5o.fsfdatafix.cs.berkeley.edu...
    > >> That sounds about right to me - I don't know of any other
    > >> commercial system that had shared nothing support before
    > >> Teradata. Of course, Teradata's market is ytics as opposed
    > >> to transaction processing.
    >
    > Mark> I don't think the first release of DB2 Parallel Edition (as
    > Mark> it was called back then) was much different than Teradata in
    > Mark> its focus on queries rather than transaction processing. I
    >
    > Oh, I guess it wasn't but now I'm not speaking for IBM - actually I
    > rarely am speaking for IBM. Let me amend that - I never speak for IBM,
    > and given that IBM never speaks for me that's fine :-)
    >
    > In fact, in general I'm curious as to people's experiences with shared
    > nothing parallelism in OLTP environments. Certainly the DB2 on Windows
    > TPC-C benchmarks show that it's possible to scale well. Still I'm
    > curious to learn more about "war stories". Just out of academic
    > interest !
    >
    > Mark, I'm not opposed to your response to Spencer that a
    > shared-nothing cluster database was/is not designed for a large number
    > of vanilla insert statements. That said, it's certainly interesting to
    > get a handle on why we see some performance results.
    >
    > I can understand Spencer's concerns. However, what will now be
    > interesting is if he can post a comparison of the insert times he can
    > generate with buffered inserts in serial and parallel mode. Then we
    > can better test the theory that what he's measuring is parallel
    > overhead.
    >
    > --
    > Pip-pip
    > Sailesh
    Parallelism is a complex subject. To partially answer your post (and some
    other posts in this thread), in an OLTP environment or a load environment
    (doing lots of inserts), there is more to it than just parallelism of the
    database. There is also parallelism of the application itself (which DB2
    exploits with its load utilities).

    I think if you look at IBM's TPC-C benchmarks, they do not use a single
    threaded application, they use parallelism at the application level in
    addition to parallelism at the database level.


    Mark A Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Partitioning Postgresql
    By phil campaigne in forum PostgreSQL / PGSQL
    Replies: 3
    Last Post: January 26th, 11:24 PM
  2. Replies: 0
    Last Post: September 17th, 05:09 PM
  3. Replies: 0
    Last Post: August 17th, 07:52 AM
  4. Partitioning HDD
    By Spinner in forum Windows XP/2000/ME
    Replies: 0
    Last Post: June 30th, 04:45 AM
  5. partitioning tables
    By Albert Punsola in forum Oracle Server
    Replies: 2
    Last Post: December 29th, 08:00 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139