[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#8430) Improved handling for large number of databases



First of all thank you for having a look at the improvement.

On 27/05/16 14:42, "Hallvard Breien Furuseth" <h.b.furuseth@usit.uio.no> wrote:

>On 27. mai 2016 12:57, juerg.bircher@helmedica.com wrote:
>> mdb_dbi_open() is however not improved with the assumption that the database
>> handle (dbi) is cached in the application.  So mdb_dbi_open() should happen only
>> once for each database during the life time of an application.
>
>It must check if the DB is open anyway, since LDMB breaks if the user
>has two DBIs to the same DB.  Though maybe we could add an optimization
>flag to skip the search, for users who know they don't reopen open DBs.
>
>Other notes:
>
>LMDB and OpenLDAP mostly use tab-width = indentation = 4.  (We should
>comment that somewhere.)  You seem to use tab-width = 8.

I will consider that for the next patch!

>
>I think MDB_WORD intends to be mdb_size_t, but should be 'unsigned
>long': It's probably no optimization to use 'long long' when that
>is not a native integer type.  But I haven't profiled that.

The MDB_WORD is used to get the appropriate word size of the CPU for
the optimised dbflag check. So on a 32 bit CPUs it should be an 32 bit
integer and on a 64 bit CPUs a 64 bit integer. But the mdb_size_t
seems always to be 64 bits?

>
>The delay in picking up env->me_dbflags is a bit troubling, since it
>means creating a new txn is no longer quite atomic.  I can't think of
>how it'll make a difference when DBIs are used correctly, but that's one
>thing people screw up.  Maybe it'd be OK if renew0() just copies it into
>mt_dbs[].md_flags without the '&', and mdb_setup_db_info() fixes it up.

Is it really atomic in original lmdb? The flags are copied from the
environment and calculated. But while copying the dbflags from the
environment they may change. So read level consistency and therefore
atomicity is not guaranteed. But I guess it just does not matter.
So picking up the flags lazily just extends the time of copying the
flags from the environment but is basically the same.
Atomicity and also isolation is a must in respect to the data but I
think not in respect to the database handles and their flags.
Maybe I am overseeing something as I do not know all the thoughts
between the lines.

>
>--
>Hallvard

Regards
Juerg