[Libreoffice-bugs] [Bug 53281] New: A double-plus-more extremely slow search/browse table in embedded HSQLDB since 3.5.5/3.6.0.beta

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53281

             Bug #: 53281
           Summary: A double-plus-more extremely slow search/browse table
                    in embedded HSQLDB since 3.5.5/3.6.0.beta
    Classification: Unclassified
           Product: LibreOffice
           Version: 3.5.5.3 release
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Keywords: regression
          Severity: major
          Priority: high
         Component: Database
        AssignedTo: libreoffice-bugs at lists.freedesktop.org
        ReportedBy: lionel at mamane.lu
                CC: admin at timbacore.co.za, david.burleigh at gmx.com,
                    dr at jochenschiffers.de, iplaw67 at yahoo.co.uk,
                    lionel at mamane.lu, michael.meeks at novell.com,
                    pmladek at suse.cz, robert at familiegrosskopf.de,
                    sbergman at redhat.com, serval2412 at yahoo.fr,
                    vstuart.foote at utsa.edu, vulcain at gmx.com
        Depends on: 51239
            Blocks: 37361, 51976, 52170


+++ This bug was initially created as a clone of Bug #51239 +++

Some of the additional DB overhead introduced by the fix to bug 47520 has been
mitigated, see bug 51239.

But some overhead remains: the code still reads all columns, even if it does
not need all of them, and caches the whole row.

This was done to follow restrictions in baseline ODBC (can read columns only
once and only in strictly monotonic column order). This is especially expensive
for JDBC, since each column read is a JNI call, crossing the C++/Java barrier,
and this is expensive.

So as not to punish backends (database access APIs) that do not have such
restrictions, the code touched by the fix to bug 47520 should be pushed to
backend-specific code:

1) Provide a generic / fast one that assumes modern behaviour,
   that backends can just use.

2) ODBC (and other weak backends, if any) should override it with
   safer / slower code, that is the "read whole row, cache whole row".
   That safer/slower version can *also* be provided by the generic layer
   and just instantiated by the backend.

   Even ODBC could interrogate the driver's capabilities and use
   the fast method if the browser supports out-of-order column retrieval
   and/or other useful extensions.
   (but pay attention to the problem of SQLGetData returning "no more data"
   for variable-length data).
   That opens another can of worms, which is that drivers lie on their
   capabilities (in either direction: report too little or too much
   capabilities).

See discussion in
http://lists.freedesktop.org/archives/libreoffice/2012-July/035387.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.