OVERLAY_CACHE_METHOD='sqlite'

OVERLAY_CACHE_METHOD='parse'

[ root@desktop ] megabaks # cat /etc/eixrc
# /etc/eixrc
#
# In this file system-wide defaults for variables related to eix binaries
# are stored, i.e. the variables set in this file override the built-in
# defaults. Both can be overridden by ~/.eixrc and by environment variables.
#
# It is strongly recommended to set here only those variables which you
# want to *differ* from the built-in defaults (or for which you have a
# particular reason why the default should never change with an eix update).
#
# *Otherwise you might miss changes in the defaults in newer eix versions*
# which may result in confusing behavior of the eix binaries.
#
# ebuilds of <=eix-0.10.3 (and >=eix-0.7.4) used to set *all* variables in
# /etc/eixrc which is not recommended anymore. If you want to get such a file
# (i.e. a file where all variables are described and set to the current
# values resp. to the built-in default values) you can redirect the output
# of the options --dump or --dump-defaults, respectively.
#
# However once more: To avoid unexpected problems
#
#   *IT IS NOT RECOMMENDED TO SET _ALL_ VARIABLES* in /etc/eixrc
#
# Only set those for which you have a reason to do so!
#
# For the available variables and their defaults, see the output of the
# options --dump or --dump-defaults.
# For more detailed explanations see the manpage of eix.

PORTDIR_CACHE_METHOD='sqlite'
OVERLAY_CACHE_METHOD='sqlite'
[ root@desktop ] megabaks # 

The following cache methods are available:
......

sqlite This  is  an  extremely  fast  cache  method  if  you  are  using  portage  with the sqlite backend, see http://en.gentoo-
                     wiki.com/wiki/Portage_SQLite_Cache       (originally       this       was        described        in        http://gentoo-
                     wiki.com/TIP_speed_up_portage_with_sqlite      which      might      be     still     accessible     at     http://gentoo-
                     wiki.info/TIP_speed_up_portage_with_sqlite).  Note that in contrast to the default metadata  cache  method  you  must  use
                     emerge --metadata before you call eix-update with this method.

                     Since  the  support of this cache method requires sqlite to be installed, this method is not necessarily compiled in.  You
                     must have emerged eix with the appropriate USE flag (or in a manual installation  used  ./configure  --with-sqlite  before
                     compilation) if you want support for this method.

                     As  for  all other cache methods, only those categories enabled by profile/category (in the main tree or some overlay) are
                     read.  If you do not want this, use sqlite* (see below).

              sqlite*
                     This is analogous to the cache method eix with the difference that all categories found in FILE are added, even those cat‐
                     egories which were not enabled by some profile/categories file.
.....

parse[#metadata-method]...
                     Get  the information from the ebuilds, parsing it using some heuristics.  Hence, this method has no security risk but pos‐
                     sibly some other problems.  For example, if variables are only set in eclasses, this method will not see  them.   Examples
                     of  problems  with this method is missing SLOT information for typical ebuilds from kde-base or stupid version numbers for
                     gcc cross-compilers.  This is the cache-method none from older eix versions (before 0.11.1).

                     It is optionally possible to append one or several strings of the form #metadata-method where metadata-method  is  any  of
                     the  above  mentioned  cache  methods  (excluding  sqlite  and cdb).  In this case, the metadata-methods are used to check
                     whether they contain newer information than the ebuild.  If this is the case, the metadata is used instead of  the  ebuild
                     (the first matching metadata wins).

                     Usually  this  is  what  you  want, especially for overlays, since the metadata is more reliable than the results of cache
                     method parse.  Of course, this is only useful if the overlay foo contains metadata which is regularly updated by the over‐
                     lay maintainer using

                     egencache --repo=foo --update

                     (whether this is done for layman overlays depends on the overlay maintainer; for your local overlays you can of course use
                     the above command manually).

                     Since this is usually what you want, the string in CACHE_METHOD_PARSE is appended by default to the cache method parse.

                     Of course, if you know in advance that the metadata information of the overlay is up-to-date, it is (slightly)  faster  to
                     use  directly  to  use the corresponding metadata method (usually metadata-flat).  The latter makes sense if you e.g. call
                     egencache from a script which you use to sync the overlay (e.g. in eix-sync).

              parse*[#metadata-method]...
                     This is essentially the same as cache method parse with the difference that variables are not expanded in variable defini‐
                     tions.   This  is  the  cache-method none* from older eix versions (before 0.11.1) and cache-method none from very old eix
                     versions (before 0.7.1)

[ megabaks@desktop ] ~ $ eix nvidia-drivers
[I] x11-drivers/nvidia-drivers
     Available versions:  71.86.11!s[1] 96.43.09!s[8] 96.43.14!s[1] (~)96.43.16!s[1] 96.43.19!s (~)173.14.12!s[8] (~)173.14.18!s[3] 173.14.20!s[1] 173.14.22!s[1] (~)173.14.25!s[1] 173.14.28!s (~)173.14.28!s[7] (~)173.14.30!s (~)180.18!s (~)180.18!s[12] (~)180.22!s (~)180.22!s[12] (~)180.25!s (~)180.25!s[12] (~)180.27!s (~)180.27!s[12] (~)180.29!s (~)180.29!s[12] (~)180.37!s (~)180.37!s[12] 180.60!s[1] (~)185.13!s (~)185.13!s[12] (~)185.18.10!s (~)185.18.10!s[12] (~)185.18.14!s (~)185.18.14!s[12] 185.18.36-r1!s[1] (~)190.42-r1!s[10] 190.42-r3!s[1] (~)190.53!s[1] (~)190.53-r1!s[1] (~)195.30!s[1] (~)195.30!s[2] (~)195.36.15!s[1] (~)256.53!s (~)256.53!s[6] (~)256.53-r1!s[4] (~)256.53-r1!s[5] (~)260.19.04!s (~)260.19.04!s[11] (~)260.19.06!s (~)260.19.06!s[9] (~)260.19.12!s (~)260.19.12!s[9] (~)260.19.21!s (~)260.19.21!s[9] [M](~)260.19.26!s [M](~)260.19.26!s[9] (~)260.19.36!s (~)260.19.36!s[7] (~)260.19.36!s[9] 260.19.44!s (~)260.19.44!s (~)260.19.44!s[9] [M](**)270.18!s [M](**)270.18!s[9] (**)270.26!s (**)270.26!s[9] (~)270.29!s (~)270.29!s[9] (~)270.30_pre!s[6] (~)270.30!s (~)270.30!s[9] (~)270.41.03!s 270.41.06!s (~)270.41.06!s (~)270.41.19!s (~)270.41.19!s (~)275.09!s (~)275.09.04!s (~)275.09.07!s (~)275.09.07!s (~)280.04!s {acpi custom-cflags distribution gtk kernel_FreeBSD kernel_linux multilib userland_BSD}
     Installed versions:  280.04!s[9](14:25:25 30.06.2011)(acpi gtk kernel_linux -custom-cflags -multilib)
     Homepage:            http://www.nvidia.com/
     Description:         NVIDIA X11 driver and GLX libraries

* x11-drivers/nvidia-drivers-rt
     Available versions:  (~)256.53!s (~)256.53!s[9] (~)260.19.06!s (~)260.19.06!s[9] (~)260.19.12!s (~)260.19.12!s[9] (~)260.19.21!s (~)260.19.21!s[9] **260.19.26!s **260.19.26!s[9] **260.19.29!s[9] **260.19.36!s[9] **270.18!s[9] **270.26!s[9] **270.29!s[9] **270.30!s[9] {acpi custom-cflags gtk kernel_linux multilib}
     Homepage:            http://www.nvidia.com/
     Description:         NVIDIA X11 driver and GLX libraries for RT kernels

[1] "amielke-overlay" layman/amielke-overlay
[2] "devnull" layman/devnull
[3] "gentoo-quebec" layman/gentoo-quebec
[4] "nelchael" layman/nelchael
[5] "pentoo" layman/pentoo
[6] "poly-c" layman/poly-c
[7] "sabayon" layman/sabayon
[8] "steev" layman/steev
[9] "stuff" layman/stuff
[10] "v-fox" layman/v-fox
[11] "wirelay" layman/wirelay
[12] "zugaina" layman/zugaina

Found 2 matches.
[ megabaks@desktop ] ~ $