Domanda

First of all, my server version, so I don't forget it: WI-V2.5.2.26540 Firebird 2.5

I have two databases on the same server. They share the same structure and (almost) same data, and differ only on the charset. In fact, database 1 is an old ISO8859_1 database that has been migrated to an UTF8 database, database 2. So:

  • Database 1: ISO8859_1. Relevant field is COD Char(21) NOT NULL
  • Database 2: UTF8 Collation UNICODE_CI_AI. Relevant field is COD Char(21) NOT NULL COLLATE UNICODE_CI_AI

Both share the same ODS version (11.2) and dialect (3).

I have a few WHERE TRIM(TRAILING FROM field) like '%something'. Problem is that this query executes virtually instantly in database 1, but is taking about a minute to complete in database 2 (I have both on the same server), in a table with about 50k records. In the meantime the fbserver process shows 25% cpu usage (1 out of the 4 cores). CPU_AFFINITY is set to use 2 cores (I guess not on the same query). Field is indexed, but PLAN is natural in both databases.

Running SELECT TRIM(TRAILING FROM field) FROM table in both databases shows the same performance issues in database 2 (but not in 1), so I really believe it must have to do with charset and the trim function.

If anyone knows how to workaround this issue, I'd be grateful. Any tips on understanding why this is happening is also very appreciated. Thanks.

È stato utile?

Soluzione

There is a known bug in Firebird 2.5.2 that makes selects on UNICODE_CI_AI fields extremely slow. This has been corrected in the upcoming 2.5.3 version.

Here is the corresponding item in the Firebird bug tracker: CORE-4125

So the workaround is to use a Firebird 2.5.3 snapshot or wait until 2.5.3 will be released. According to the Roadmap this should happen in Q1/2014.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top