Bug 53281 - A double-plus-more extremely slow search/browse table in embedded HSQLDB since 3.5.5/3.6.0.beta
Summary: A double-plus-more extremely slow search/browse table in embedded HSQLDB sinc...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.5.5.3 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: hfmuc2012 target:4.1.0 target:4.0.0.0...
Keywords: regression
Depends on: 51239
Blocks: mab3.5 51976 52170
  Show dependency treegraph
 
Reported: 2012-08-09 09:16 UTC by Lionel Elie Mamane
Modified: 2012-12-06 18:54 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2012-08-09 09:16:19 UTC
+++ 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
Comment 1 Jochen 2012-08-27 17:50:23 UTC
Status changed to NEW
Comment 2 Not Assigned 2012-12-06 18:42:11 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bd60c90f854954aad4361e6de9829e0db2ac2ccc

fdo#53281 Don't cache whole row in KeySet



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 3 Lionel Elie Mamane 2012-12-06 18:44:41 UTC
This particular performance problem has been fixed.

See bug 52170, bug 51976 for possibly other performance problems which can now be tested / worked on.
Comment 4 Not Assigned 2012-12-06 18:48:34 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=59375da788af698aa619cb763adaf0428a4bb81e&g=libreoffice-4-0

fdo#53281 Don't cache whole row in KeySet


It will be available in LibreOffice 4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.