Re: Posting for Keith Bostic

#1

"Sarge" <not (AT) home (DOT) com> wrote

Quote:

One comment. Because the DB->get method returns all of the duplicate
data items in a single call, the amount of memory required is likely to
be large. So, you may want to use the DBcursor->c_get method with the
bulk-get flags rather than DB->get, as the memory required should be
less.

Doesn't a bulk DBC->c_get also return all dup items in a single call?

No.

Quote:

When using DB->get for a bulk retrieval, the library creates a cursor for
you,
and ends up calling DBC->c_get anyway, doesn't it?

Yes.

Quote:

Why would the memory requirements be less?

The cursor version of the call does not need to return all of the dup items in a
single call because the cursor maintains a position in the database, and thus
can return subsequent items in a subsequent call, if the items do not entirely
fit into the memory made available in a single call. There's no "position in
the database" held by the DB->get call, and so it either has to return all of the
dup items in the memory made available for the single call, or fail.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com

#2

Ok, now that I've read the docs again, I see that you must continue calling
DBC->c_get with DB_MULTIPLE|DB_NEXT_DUP until DB_NOTFOUND is returned.
Thanks for clearing this up.

Is there a significant speed increase using bulk reads versus traversing the
records with a cursor one at a time?

--Sarge

#3

"Sarge" <not (AT) home (DOT) com> wrote

Quote:

Ok, now that I've read the docs again, I see that you must continue calling
DBC->c_get with DB_MULTIPLE|DB_NEXT_DUP until DB_NOTFOUND is returned.
Thanks for clearing this up.

Is there a significant speed increase using bulk reads versus traversing the
records with a cursor one at a time?

Yes; the call stack to the actual entries being returned is fairly deep, and
entries are copied out in page chunks rather than as individual entries.

Bulk get is fast -- I've seen tests where Berkeley DB returned 4-6 million
rows per second on commodity hardware.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: Posting for Keith Bostic

comp.databases.berkeley-db comp.databases.berkeley-db

Re: Posting for Keith Bostic - 08-18-2003 , 08:43 PM

Re: Posting for Keith Bostic - 08-20-2003 , 10:08 AM

Re: Posting for Keith Bostic - 08-20-2003 , 05:39 PM