@_generative()
def yield_per(self, count):
    "Yield only ``count`` rows at a time.\n\n        The purpose of this method is when fetching very large result sets\n        (> 10K rows), to batch results in sub-collections and yield them\n        out partially, so that the Python interpreter doesn't need to declare\n        very large areas of memory which is both time consuming and leads\n        to excessive memory use.   The performance from fetching hundreds of\n        thousands of rows can often double when a suitable yield-per setting\n        (e.g. approximately 1000) is used, even with DBAPIs that buffer\n        rows (which are most).\n\n        The :meth:`.Query.yield_per` method **is not compatible with most\n        eager loading schemes, including subqueryload and joinedload with\n        collections**.  For this reason, it may be helpful to disable\n        eager loads, either unconditionally with\n        :meth:`.Query.enable_eagerloads`::\n\n            q = sess.query(Object).yield_per(100).enable_eagerloads(False)\n\n        Or more selectively using :func:`.lazyload`; such as with\n        an asterisk to specify the default loader scheme::\n\n            q = sess.query(Object).yield_per(100).\\\n                options(lazyload('*'), joinedload(Object.some_related))\n\n        .. warning::\n\n            Use this method with caution; if the same instance is\n            present in more than one batch of rows, end-user changes\n            to attributes will be overwritten.\n\n            In particular, it's usually impossible to use this setting\n            with eagerly loaded collections (i.e. any lazy='joined' or\n            'subquery') since those collections will be cleared for a\n            new load when encountered in a subsequent result batch.\n            In the case of 'subquery' loading, the full result for all\n            rows is fetched which generally defeats the purpose of\n            :meth:`~sqlalchemy.orm.query.Query.yield_per`.\n\n            Also note that while\n            :meth:`~sqlalchemy.orm.query.Query.yield_per` will set the\n            ``stream_results`` execution option to True, currently\n            this is only understood by\n            :mod:`~sqlalchemy.dialects.postgresql.psycopg2` dialect\n            which will stream results using server side cursors\n            instead of pre-buffer all rows for this query. Other\n            DBAPIs **pre-buffer all rows** before making them\n            available.  The memory use of raw database rows is much less\n            than that of an ORM-mapped object, but should still be taken into\n            consideration when benchmarking.\n\n        .. seealso::\n\n            :meth:`.Query.enable_eagerloads`\n\n        "
    self._yield_per = count
    self._execution_options = self._execution_options.union({'stream_results': True})
Yield only ``count`` rows at a time.

The purpose of this method is when fetching very large result sets
(> 10K rows), to batch results in sub-collections and yield them
out partially, so that the Python interpreter doesn't need to declare
very large areas of memory which is both time consuming and leads
to excessive memory use.   The performance from fetching hundreds of
thousands of rows can often double when a suitable yield-per setting
(e.g. approximately 1000) is used, even with DBAPIs that buffer
rows (which are most).

The :meth:`.Query.yield_per` method **is not compatible with most
eager loading schemes, including subqueryload and joinedload with
collections**.  For this reason, it may be helpful to disable
eager loads, either unconditionally with
:meth:`.Query.enable_eagerloads`::

    q = sess.query(Object).yield_per(100).enable_eagerloads(False)

Or more selectively using :func:`.lazyload`; such as with
an asterisk to specify the default loader scheme::

    q = sess.query(Object).yield_per(100).\
        options(lazyload('*'), joinedload(Object.some_related))

.. warning::

    Use this method with caution; if the same instance is
    present in more than one batch of rows, end-user changes
    to attributes will be overwritten.

    In particular, it's usually impossible to use this setting
    with eagerly loaded collections (i.e. any lazy='joined' or
    'subquery') since those collections will be cleared for a
    new load when encountered in a subsequent result batch.
    In the case of 'subquery' loading, the full result for all
    rows is fetched which generally defeats the purpose of
    :meth:`~sqlalchemy.orm.query.Query.yield_per`.

    Also note that while
    :meth:`~sqlalchemy.orm.query.Query.yield_per` will set the
    ``stream_results`` execution option to True, currently
    this is only understood by
    :mod:`~sqlalchemy.dialects.postgresql.psycopg2` dialect
    which will stream results using server side cursors
    instead of pre-buffer all rows for this query. Other
    DBAPIs **pre-buffer all rows** before making them
    available.  The memory use of raw database rows is much less
    than that of an ORM-mapped object, but should still be taken into
    consideration when benchmarking.

.. seealso::

    :meth:`.Query.enable_eagerloads`
@_generative()
def yield_per(self, count):
    "Yield only ``count`` rows at a time.\n\n        The purpose of this method is when fetching very large result sets\n        (> 10K rows), to batch results in sub-collections and yield them\n        out partially, so that the Python interpreter doesn't need to declare\n        very large areas of memory which is both time consuming and leads\n        to excessive memory use.   The performance from fetching hundreds of\n        thousands of rows can often double when a suitable yield-per setting\n        (e.g. approximately 1000) is used, even with DBAPIs that buffer\n        rows (which are most).\n\n        The :meth:`.Query.yield_per` method **is not compatible with most\n        eager loading schemes, including subqueryload and joinedload with\n        collections**.  For this reason, it may be helpful to disable\n        eager loads, either unconditionally with\n        :meth:`.Query.enable_eagerloads`::\n\n            q = sess.query(Object).yield_per(100).enable_eagerloads(False)\n\n        Or more selectively using :func:`.lazyload`; such as with\n        an asterisk to specify the default loader scheme::\n\n            q = sess.query(Object).yield_per(100).\\\n                options(lazyload('*'), joinedload(Object.some_related))\n\n        .. warning::\n\n            Use this method with caution; if the same instance is\n            present in more than one batch of rows, end-user changes\n            to attributes will be overwritten.\n\n            In particular, it's usually impossible to use this setting\n            with eagerly loaded collections (i.e. any lazy='joined' or\n            'subquery') since those collections will be cleared for a\n            new load when encountered in a subsequent result batch.\n            In the case of 'subquery' loading, the full result for all\n            rows is fetched which generally defeats the purpose of\n            :meth:`~sqlalchemy.orm.query.Query.yield_per`.\n\n            Also note that while\n            :meth:`~sqlalchemy.orm.query.Query.yield_per` will set the\n            ``stream_results`` execution option to True, currently\n            this is only understood by\n            :mod:`~sqlalchemy.dialects.postgresql.psycopg2` dialect\n            which will stream results using server side cursors\n            instead of pre-buffer all rows for this query. Other\n            DBAPIs **pre-buffer all rows** before making them\n            available.  The memory use of raw database rows is much less\n            than that of an ORM-mapped object, but should still be taken into\n            consideration when benchmarking.\n\n        .. seealso::\n\n            :meth:`.Query.enable_eagerloads`\n\n        "
    self._yield_per = count
    self._execution_options = self._execution_options.union({'stream_results': True})