Loading ...
Sorry, an error occurred while loading the content.

Re: [firebird-support] Perfomance problems

Expand Messages
  • Carsten Schäfer
    ... The database is freshly restored, so i think all indexes should be optimal created. I think there are some serious bugs in the plan optimizer. For me it
    Message 1 of 22 , Nov 30, 2004
    • 0 Attachment
      Arno Brinkman wrote:
      > Hi Carsten,

      >
      > Good question (may be wrong selectivity in index statistics), but the
      > JOIN order has been changed and that is most effective result at the
      > moment.
      >
      >> Do I have to create compound indexes on every combination of
      >> or-clauses ?
      >
      > No, only when a compound index is usefull (all fields are used for
      > filtering).
      >
      >> My problem is that the user can construct this select and it can
      >> consist of much more joins with other tables and can be much more
      >> complex (abitrary composition of 'or' and 'and' clauses).
      >> So Its impossible to create indexes for all possibilities.
      >
      > If you remove the compound index, the query below should give the
      > same PLAN.
      >
      > SELECT
      > t_apos.ID_APOS
      > FROM
      > t_apos
      > JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
      > WHERE
      > F_ID_WERKSTOFF = 11 OR
      > F_ID_WERKSTOFF = 245
      >
      > In this query i force the optimizer to ignore f_id_auftrag to be used
      > in a index, thus it will put t_apos at the first position in the join
      > order.
      >
      > Could you run SET STATISTICS INDEX <name> for every index on t_apos
      > and t_auftrag to be sure those are correct and then try also again
      > with your original query.
      >

      The database is freshly restored, so i think all indexes should be optimal
      created.
      I think there are some serious bugs in the plan optimizer.
      For me it looks random if the optimzer chooses to take a natural join (very
      slow) or an index join (very fast)
      If i use your trick and do the following query:
      SELECT t_apos.ID_APOS
      FROM t_apos
      JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
      WHERE t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23'
      PLAN JOIN (T_APOS NATURAL,T_AUFTRAG INDEX (RDB$PRIMARY39))
      Firebird makes a natural join and doesn't use the index on f_adatum
      (duration 10sec).
      If i remove your trick(+0) the query is fast (<100ms) and the index is used
      PLAN JOIN (T_AUFTRAG INDEX (IND_AUFTRAG_ADATUM),T_APOS INDEX (RDB$FOREIGN1))

      The following query is slow
      SELECT t_apos.ID_APOS
      FROM t_apos
      JOIN t_auftrag ON f_id_auftrag = id_auftrag
      WHERE f_id_werkstoff = 10
      or t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23'
      PLAN JOIN (T_AUFTRAG NATURAL,T_APOS INDEX (RDB$FOREIGN1))

      and there is no chance to get it fast.
      I changed it to:
      SELECT t_apos.ID_APOS
      FROM t_apos
      JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
      WHERE f_id_werkstoff = 10
      or (t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23' or
      2=0)
      PLAN JOIN (T_APOS NATURAL,T_AUFTRAG INDEX (RDB$PRIMARY39))
      i tried all possibilities, but Firebird always makes a natural join for
      this.
      I think it's a bug.

      mfg
      Carsten
    • Arno Brinkman
      Hi Carsten, ... Should be, but check to be sure. ... This is not a bug, but as designed. I agree that he could do (and should do) a better job in some
      Message 2 of 22 , Dec 1, 2004
      • 0 Attachment
        Hi Carsten,

        > > If you remove the compound index, the query below should give the
        > > same PLAN.
        > >
        > > SELECT
        > > t_apos.ID_APOS
        > > FROM
        > > t_apos
        > > JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
        > > WHERE
        > > F_ID_WERKSTOFF = 11 OR
        > > F_ID_WERKSTOFF = 245
        > >
        > > In this query i force the optimizer to ignore f_id_auftrag to be used
        > > in a index, thus it will put t_apos at the first position in the join
        > > order.
        > >
        > > Could you run SET STATISTICS INDEX <name> for every index on t_apos
        > > and t_auftrag to be sure those are correct and then try also again
        > > with your original query.
        > >
        >
        > The database is freshly restored, so i think all indexes should be optimal
        > created.

        Should be, but check to be sure.

        > I think there are some serious bugs in the plan optimizer.

        This is not a bug, but as designed.
        I agree that he could do (and should do) a better job in some circumstances, but
        the optimizer hasn't serious bugs.

        > For me it looks random if the optimzer chooses to take a natural join (very
        > slow) or an index join (very fast)

        Certainly not random, the optimizer calculates the join order based on estimated
        values and this is not random.

        > If i use your trick and do the following query:
        > SELECT t_apos.ID_APOS
        > FROM t_apos
        > JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
        > WHERE t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23'
        > PLAN JOIN (T_APOS NATURAL,T_AUFTRAG INDEX (RDB$PRIMARY39))

        This is a complete different query as the previous message?

        > Firebird makes a natural join and doesn't use the index on f_adatum
        > (duration 10sec).

        Yes, because only a index can be used for f_adatum and/or id_auftrag and both
        are in table t_auftrag.
        Again, please use everywhere aliasses so it's readable to what tables every
        field belongs.

        > If i remove your trick(+0) the query is fast (<100ms) and the index is used
        > PLAN JOIN (T_AUFTRAG INDEX (IND_AUFTRAG_ADATUM),T_APOS INDEX (RDB$FOREIGN1))

        Thus the optimizer has calculated the join order correct here.

        > The following query is slow
        > SELECT t_apos.ID_APOS
        > FROM t_apos
        > JOIN t_auftrag ON f_id_auftrag = id_auftrag
        > WHERE f_id_werkstoff = 10
        > or t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23'
        > PLAN JOIN (T_AUFTRAG NATURAL,T_APOS INDEX (RDB$FOREIGN1))

        Is there a index on f_id_werkstoff ? and more important to which table does it
        belong.
        If f_id_werkstoff is in t_apos and f_adatum in t_auftrag then never a index can
        be used for the condition (t_apos.f_id_werkstoff = x OR t_auftrag.f_adatum = x),
        because both tables are not "available" at the same time for evaluation.

        > and there is no chance to get it fast.
        > I changed it to:
        > SELECT t_apos.ID_APOS
        > FROM t_apos
        > JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
        > WHERE f_id_werkstoff = 10
        > or (t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23' or
        > 2=0)
        > PLAN JOIN (T_APOS NATURAL,T_AUFTRAG INDEX (RDB$PRIMARY39))
        > i tried all possibilities, but Firebird always makes a natural join for
        > this.

        With adding "OR 2=0" the optimizer is never able to use indexes on the whole OR
        condition, thus above PLAN is as expected.

        > I think it's a bug.

        I don't think, but if you're sure the optimizer can do better i want a test-case
        so i'm able to reproduce it.

        Regards,
        Arno Brinkman
        ABVisie

        -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        Firebird open source database (based on IB-OE) with many SQL-99 features :
        http://www.firebirdsql.org
        http://www.firebirdsql.info
        http://www.fingerbird.de/
        http://www.comunidade-firebird.org/

        Support list for Interbase and Firebird users :
        firebird-support@yahoogroups.com

        Nederlandse firebird nieuwsgroep :
        news://newsgroups.firebirdsql.info
      • Carsten Schäfer
        ... This is not complete different, just another field, both have an index. ... In my first message i posted the table definitions, so theoreticaly you can
        Message 3 of 22 , Dec 1, 2004
        • 0 Attachment
          "Arno Brinkman" wrote:
          > Hi Carsten,
          >
          >
          > Certainly not random, the optimizer calculates the join order based
          > on estimated values and this is not random.
          >
          >> If i use your trick and do the following query:
          >> SELECT t_apos.ID_APOS
          >> FROM t_apos
          >> JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
          >> WHERE t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004
          >> 11:23' PLAN JOIN (T_APOS NATURAL,T_AUFTRAG INDEX (RDB$PRIMARY39))
          >
          > This is a complete different query as the previous message?

          This is not complete different, just another field, both have an index.

          >> The following query is slow
          >> SELECT t_apos.ID_APOS
          >> FROM t_apos
          >> JOIN t_auftrag ON f_id_auftrag = id_auftrag
          >> WHERE f_id_werkstoff = 10
          >> or t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004
          >> 11:23'
          >> PLAN JOIN (T_AUFTRAG NATURAL,T_APOS INDEX (RDB$FOREIGN1))
          >
          > Is there a index on f_id_werkstoff ? and more important to which
          > table does it belong.
          > If f_id_werkstoff is in t_apos and f_adatum in t_auftrag then never a
          > index can be used for the condition (t_apos.f_id_werkstoff = x OR
          > t_auftrag.f_adatum = x), because both tables are not "available" at
          > the same time for evaluation.
          >
          >> and there is no chance to get it fast.
          >> I changed it to:
          >> SELECT t_apos.ID_APOS
          >> FROM t_apos
          >> JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
          >> WHERE f_id_werkstoff = 10
          >> or (t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004
          >> 11:23' or 2=0)
          >> PLAN JOIN (T_APOS NATURAL,T_AUFTRAG INDEX (RDB$PRIMARY39))
          >> i tried all possibilities, but Firebird always makes a natural join
          >> for
          >> this.
          >
          > With adding "OR 2=0" the optimizer is never able to use indexes on
          > the whole OR condition, thus above PLAN is as expected.
          >
          >> I think it's a bug.
          >
          > I don't think, but if you're sure the optimizer can do better i want
          > a test-case so i'm able to reproduce it.
          >

          In my first message i posted the table definitions, so theoreticaly you can
          test it.
          f_id_werkstoff is in t_apos and is a foreign key so it has an index.
          What i don't understand: I have 2 queries, both are very fast (<100ms) ,
          but when i compound them with 'or' the query is not usable anymore (>10sec).
          An or-clause should never take much longer than the addition of the 2
          clauses.

          mfg
          Carsten.
        • Svein Erling Tysvær
          ... I suspect doing an addition of the two clauses would be more like SELECT t_apos.ID_APOS FROM t_apos JOIN t_auftrag ON f_id_auftrag = id_auftrag WHERE
          Message 4 of 22 , Dec 1, 2004
          • 0 Attachment
            --- In firebird-support@yahoogroups.com, Carsten Schäfer wrote:
            > The following query is slow
            > SELECT t_apos.ID_APOS
            > FROM t_apos
            > JOIN t_auftrag ON f_id_auftrag = id_auftrag
            > WHERE f_id_werkstoff = 10
            > or t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004
            > 11:23'
            > PLAN JOIN (T_AUFTRAG NATURAL,T_APOS INDEX (RDB$FOREIGN1))
            >
            > What i don't understand: I have 2 queries, both are very fast
            > (<100ms), but when i compound them with 'or' the query is not usable
            > anymore (>10sec). An or-clause should never take much longer than
            > the addition of the 2 clauses.

            I suspect doing an addition of the two clauses would be more like

            SELECT t_apos.ID_APOS
            FROM t_apos
            JOIN t_auftrag ON f_id_auftrag = id_auftrag
            WHERE f_id_werkstoff = 10
            UNION
            SELECT t_apos.ID_APOS
            FROM t_apos
            JOIN t_auftrag ON f_id_auftrag = id_auftrag
            WHERE t_auftrag.f_adatum between '31.10.2004 00:00' AND
            '02.12.2004 11:23'

            Firebird attempts to find one optimal plan, what you seem to desire is
            two separate plans with the result joined together. In many cases that
            would be sub-optimal.

            That being said, I do think Firebird is better at handling INNER JOIN
            and AND than OUTER JOIN and OR, just like I am better at solving one
            problem at a time than several (I can wash my hands or write programs,
            doing both at the same time ruins my computer!). It can be extremely
            difficult to unleash the full power of Firebird to users, and at the
            same time prevent them from suffering the pitfalls. Firebird will
            inevitably punish you for issuing an all-too-demanding query.

            Set
          • Arno Brinkman
            Hi Carsten, ... Just another field is different enough. You can t compare apples and oranges. ... I hope you understand it s much easier posting with aliasses.
            Message 5 of 22 , Dec 1, 2004
            • 0 Attachment
              Hi Carsten,

              > >> If i use your trick and do the following query:
              > >> SELECT t_apos.ID_APOS
              > >> FROM t_apos
              > >> JOIN t_auftrag ON f_id_auftrag + 0 = id_auftrag
              > >> WHERE t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004
              > >> 11:23' PLAN JOIN (T_APOS NATURAL,T_AUFTRAG INDEX (RDB$PRIMARY39))
              > >
              > > This is a complete different query as the previous message?
              >
              > This is not complete different, just another field, both have an index.

              Just another field is different enough. You can't compare apples and oranges.

              > In my first message i posted the table definitions, so theoreticaly you can
              > test it.

              I hope you understand it's much easier posting with aliasses. Then there's no
              need to search in my history to your first message.

              > f_id_werkstoff is in t_apos and is a foreign key so it has an index.

              I wrote :

              > > If f_id_werkstoff is in t_apos and f_adatum in t_auftrag then never a
              > > index can be used for the condition (t_apos.f_id_werkstoff = x OR
              > > t_auftrag.f_adatum = x), because both tables are not "available" at
              > > the same time for evaluation.

              > What i don't understand: I have 2 queries, both are very fast (<100ms) ,
              > but when i compound them with 'or' the query is not usable anymore (>10sec).
              > An or-clause should never take much longer than the addition of the 2
              > clauses.

              You can't say easily i have 2 queries and when i combine them to 1 they should
              at least be the same performance of the single queries performance added
              together.

              1)

              SELECT
              t_apos.ID_APOS
              FROM
              t_apos
              JOIN t_auftrag ON t_apos.f_id_auftrag = t_auftrag.id_auftrag
              WHERE
              t_apos.f_id_werkstoff = 10

              In this query both the index on id_auftrag and f_id_werkstoff can be used, thus
              both tables use a index for lookup.

              2)
              SELECT
              t_apos.ID_APOS
              FROM
              t_apos
              JOIN t_auftrag ON t_apos.f_id_auftrag = t_auftrag.id_auftrag
              WHERE
              (t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23')

              In this query both the index on f_id_auftrag and f_adatum can be used, thus both
              tables use a index for lookup.

              3)
              SELECT
              t_apos.ID_APOS
              FROM
              t_apos
              JOIN t_auftrag ON t_apos.f_id_auftrag = t_auftrag.id_auftrag
              WHERE
              (t_apos.f_id_werkstoff = 10) OR
              (t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23')

              The where clause can never use a index because not both table t_apos and
              t_auftrag can be "active" at the same time for index lookup.

              In this case you want a UNION ALL instead of building a new query.

              SELECT
              t_apos.ID_APOS
              FROM
              t_apos
              JOIN t_auftrag ON t_apos.f_id_auftrag = t_auftrag.id_auftrag
              WHERE
              t_apos.f_id_werkstoff = 10
              UNION ALL
              SELECT
              t_apos.ID_APOS
              FROM
              t_apos
              JOIN t_auftrag ON t_apos.f_id_auftrag = t_auftrag.id_auftrag
              WHERE
              (t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004 11:23')

              Remove the ALL from the UNION if you don't want duplicate values in the final
              result.

              Regards,
              Arno Brinkman
              ABVisie

              -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
              Firebird open source database (based on IB-OE) with many SQL-99 features :
              http://www.firebirdsql.org
              http://www.firebirdsql.info
              http://www.fingerbird.de/
              http://www.comunidade-firebird.org/

              Support list for Interbase and Firebird users :
              firebird-support@yahoogroups.com

              Nederlandse firebird nieuwsgroep :
              news://newsgroups.firebirdsql.info
            • Carsten Schäfer
              ... The union works as fast as expected. Is there a rule when to take a union and when to take an or-clause ? Has somebody ever made a real world application
              Message 6 of 22 , Dec 1, 2004
              • 0 Attachment
                "Arno Brinkman" wrote:
                > Hi Carsten,
                >
                >
                > In this case you want a UNION ALL instead of building a new query.
                >
                > SELECT
                > t_apos.ID_APOS
                > FROM
                > t_apos
                > JOIN t_auftrag ON t_apos.f_id_auftrag = t_auftrag.id_auftrag
                > WHERE
                > t_apos.f_id_werkstoff = 10
                > UNION ALL
                > SELECT
                > t_apos.ID_APOS
                > FROM
                > t_apos
                > JOIN t_auftrag ON t_apos.f_id_auftrag = t_auftrag.id_auftrag
                > WHERE
                > (t_auftrag.f_adatum between '31.10.2004 00:00' AND '02.12.2004
                > 11:23')
                >

                The union works as fast as expected.
                Is there a rule when to take a union and when to take an or-clause ?
                Has somebody ever made a real world application where the end-user can
                self-construct the queries ?
                My examples were very easy.
                In reality the users sometimes make much more complicated queries and it
                seems impossible for me to build optimal queries so that Firebird uses the
                optimal plan.

                mfg
                Carsten
              • Arno Brinkman
                Hi, ... Not that i m aware off, there are some many situations that it s difficult to describe in a few lines. ... I m sure there is, but with self-construct a
                Message 7 of 22 , Dec 1, 2004
                • 0 Attachment
                  Hi,

                  > The union works as fast as expected.
                  > Is there a rule when to take a union and when to take an or-clause ?

                  Not that i'm aware off, there are some many situations that it's difficult
                  to describe in a few lines.

                  > Has somebody ever made a real world application where the end-user can
                  > self-construct the queries ?

                  I'm sure there is, but with self-construct a user can always make something
                  slowly. Just join 2 large tables together with 1 = 1.

                  > My examples were very easy.
                  > In reality the users sometimes make much more complicated queries and it
                  > seems impossible for me to build optimal queries so that Firebird uses the
                  > optimal plan.

                  The problem in your example was due OR-ing two different fields from
                  different tables. If those fields were from the same table, it would be
                  better to optimizer (in 1 query).

                  Regards,
                  Arno Brinkman
                  ABVisie

                  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                  Firebird open source database (based on IB-OE) with many SQL-99 features :
                  http://www.firebirdsql.org
                  http://www.firebirdsql.info
                  http://www.fingerbird.de/
                  http://www.comunidade-firebird.org/

                  Support list for Interbase and Firebird users :
                  firebird-support@yahoogroups.com

                  Nederlandse firebird nieuwsgroep :
                  news://80.126.130.81
                • Alan McDonald
                  The Release Notes (page 52) states of the embedded server: Database access[:] Only “true local” access is allowed. The embedded server has no support for
                  Message 8 of 22 , Dec 1, 2004
                  • 0 Attachment
                    The Release Notes (page 52) states of the embedded server:

                    Database access[:] Only “true local” access is allowed. The embedded server
                    has no support for remote protocols, so even access via "localhost" won't
                    work.

                    Helen Borrie on Nov 18 states:
                    There are more possibilities in the mix. From the same machine, a user
                    could be working with a local database using the embedded server and,
                    simultaneously, connecting from the same application (and client library)
                    to a database on a remote server.

                    I'm a little confused now. Are the release notes in error?
                    I've tried renaming the fbembed.dll to gds32.dll into the application
                    directory of one of my apps and it appears to connect no problem with a
                    remote database server.

                    Can I therefore distribute fbembed.dll (renamed to gds32.dll or
                    fbclient.dll - whichever I need) all the time - i.e. forget about the client
                    only lib (if distro size is not important)?
                    thanks
                    Alan
                  • Peter Lee
                    Hi Alan, This is what we understand to be the case... and we re doing that now (in beta :-) ) with no problems. So, for a single computer install, we just
                    Message 9 of 22 , Dec 1, 2004
                    • 0 Attachment
                      Hi Alan,

                      This is what we understand to be the case... and we're doing that now
                      (in beta :-) ) with no problems.

                      So, for a single computer install, we just deploy fbembed.dll (and
                      associated files)... on a 'server' machine, we do a full fb server
                      install, with the real client.

                      Regards,

                      Peter Lee

                      Alan McDonald wrote:

                      >The Release Notes (page 52) states of the embedded server:
                      >
                      >Database access[:] Only “true local” access is allowed. The embedded server
                      >has no support for remote protocols, so even access via "localhost" won't
                      >work.
                      >
                      >Helen Borrie on Nov 18 states:
                      >There are more possibilities in the mix. From the same machine, a user
                      >could be working with a local database using the embedded server and,
                      >simultaneously, connecting from the same application (and client library)
                      >to a database on a remote server.
                      >
                      >I'm a little confused now. Are the release notes in error?
                      >I've tried renaming the fbembed.dll to gds32.dll into the application
                      >directory of one of my apps and it appears to connect no problem with a
                      >remote database server.
                      >
                      >Can I therefore distribute fbembed.dll (renamed to gds32.dll or
                      >fbclient.dll - whichever I need) all the time - i.e. forget about the client
                      >only lib (if distro size is not important)?
                      >thanks
                      >Alan
                      >
                      >
                      >
                      >
                      >
                      >
                      >Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >


                      --
                      Peter Lee Mobile: +61 412 011 174 ptle@...
                      -----------------------------------------------------------------------
                      Rising Software Australia Pty. Ltd. http://www.risingsoftware.com/
                      Publishers of 'Auralia' - Ear Training and 'Musition' - Theory Training
                      Ph: +61 3 9894 4788 FAX: +61 3 9894 3362 USA Freecall: 1 888 667 7839
                    • Alan McDonald
                      ... Why do you install the real client on any machine? Alan
                      Message 10 of 22 , Dec 1, 2004
                      • 0 Attachment
                        > Hi Alan,
                        >
                        > This is what we understand to be the case... and we're doing that now
                        > (in beta :-) ) with no problems.
                        >
                        > So, for a single computer install, we just deploy fbembed.dll (and
                        > associated files)... on a 'server' machine, we do a full fb server
                        > install, with the real client.
                        >
                        > Regards,
                        >
                        > Peter Lee

                        Why do you install the real client on any machine?
                        Alan
                      • Alan McDonald
                        ... oh - and how do you get a fbembed.dll with the same version stamping as a compatible gds32.dll? i.e. Version 6.3.0.4306 instead of 1.5 Alan
                        Message 11 of 22 , Dec 1, 2004
                        • 0 Attachment
                          > Hi Alan,
                          >
                          > This is what we understand to be the case... and we're doing that now
                          > (in beta :-) ) with no problems.
                          >
                          > So, for a single computer install, we just deploy fbembed.dll (and
                          > associated files)... on a 'server' machine, we do a full fb server
                          > install, with the real client.
                          >
                          > Regards,
                          >
                          > Peter Lee
                          >

                          oh - and how do you get a fbembed.dll with the same version stamping as a
                          "compatible" gds32.dll?
                          i.e. Version 6.3.0.4306
                          instead of 1.5
                          Alan
                        • Alan McDonald
                          ... Peter, Have your tests so far revealed any performance difference using a 1.4Mb client compared with a 340Kb client? Alan
                          Message 12 of 22 , Dec 1, 2004
                          • 0 Attachment
                            > Hi Alan,
                            >
                            > This is what we understand to be the case... and we're doing that now
                            > (in beta :-) ) with no problems.
                            >
                            > So, for a single computer install, we just deploy fbembed.dll (and
                            > associated files)... on a 'server' machine, we do a full fb server
                            > install, with the real client.
                            >
                            > Regards,
                            >
                            > Peter Lee

                            Peter,
                            Have your tests so far revealed any performance difference using a 1.4Mb
                            client compared with a 340Kb client?
                            Alan
                          • Peter Lee
                            Hi Alan, Not sure why we install the real client on the server... I think that it gets installed by default with a server install using the installshield
                            Message 13 of 22 , Dec 1, 2004
                            • 0 Attachment
                              Hi Alan,

                              Not sure why we install the real client on the server... I think that it
                              gets installed by default with a server install using the installshield
                              packages from MWA (http://www.mwasoftware.co.uk/firebird/)! I guess it
                              might be handy if somebody decides to play with FB tools...

                              We rename fbembed.dll to fbclient.dll... and put it in our program
                              directory, so we don't worry about gds32.dll at all. However, we are
                              working on a rewrite of an exisitng app, with no installed base relying
                              on gds32.dll...

                              Regards,

                              Peter Lee

                              Alan McDonald wrote:

                              >>Hi Alan,
                              >>
                              >>This is what we understand to be the case... and we're doing that now
                              >>(in beta :-) ) with no problems.
                              >>
                              >>So, for a single computer install, we just deploy fbembed.dll (and
                              >>associated files)... on a 'server' machine, we do a full fb server
                              >>install, with the real client.
                              >>
                              >>Regards,
                              >>
                              >>Peter Lee
                              >>
                              >>
                              >>
                              >
                              >oh - and how do you get a fbembed.dll with the same version stamping as a
                              >"compatible" gds32.dll?
                              >i.e. Version 6.3.0.4306
                              >instead of 1.5
                              >Alan
                              >
                              >
                              >
                              >
                              >
                              >
                              >Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >


                              --
                              Peter Lee Mobile: +61 412 011 174 ptle@...
                              -----------------------------------------------------------------------
                              Rising Software Australia Pty. Ltd. http://www.risingsoftware.com/
                              Publishers of 'Auralia' - Ear Training and 'Musition' - Theory Training
                              Ph: +61 3 9894 4788 FAX: +61 3 9894 3362 USA Freecall: 1 888 667 7839
                            • Peter Lee
                              Hi Alan, No... but that is only anecdotal evidence... haven t done any serious performance testing yet. Do you mean in query performance or program loading
                              Message 14 of 22 , Dec 1, 2004
                              • 0 Attachment
                                Hi Alan,

                                No... but that is only anecdotal evidence... haven't done any serious
                                performance testing yet. Do you mean in query performance or program
                                loading type issues? We certainly don't notice it in program loading...
                                having said that, I've never been completely clear on how Windows loads
                                dlls, and whether everything is loaded all at once etc.

                                Our application has database access just about everywhere, but select
                                result sets are generally very small... at least for 99% of users, so
                                given the deployment flexibility, we'd probably just take a performance
                                hit if it exists, or try to rework some SQL.

                                Regards,

                                Peter Lee

                                Alan McDonald wrote:

                                >>Hi Alan,
                                >>
                                >>This is what we understand to be the case... and we're doing that now
                                >>(in beta :-) ) with no problems.
                                >>
                                >>So, for a single computer install, we just deploy fbembed.dll (and
                                >>associated files)... on a 'server' machine, we do a full fb server
                                >>install, with the real client.
                                >>
                                >>Regards,
                                >>
                                >>Peter Lee
                                >>
                                >>
                                >
                                >Peter,
                                >Have your tests so far revealed any performance difference using a 1.4Mb
                                >client compared with a 340Kb client?
                                >Alan
                                >
                                >
                                >
                                >
                                >
                                >
                                >Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >


                                --
                                Peter Lee Mobile: +61 412 011 174 ptle@...
                                -----------------------------------------------------------------------
                                Rising Software Australia Pty. Ltd. http://www.risingsoftware.com/
                                Publishers of 'Auralia' - Ear Training and 'Musition' - Theory Training
                                Ph: +61 3 9894 4788 FAX: +61 3 9894 3362 USA Freecall: 1 888 667 7839
                              • Alan McDonald
                                ... As I understand it he server part of the embedded server is loaded dynamically - so the client may load but the server part will not load until a local
                                Message 15 of 22 , Dec 1, 2004
                                • 0 Attachment
                                  > Hi Alan,
                                  >
                                  > No... but that is only anecdotal evidence... haven't done any serious
                                  > performance testing yet. Do you mean in query performance or program
                                  > loading type issues? We certainly don't notice it in program loading...
                                  > having said that, I've never been completely clear on how Windows loads
                                  > dlls, and whether everything is loaded all at once etc.

                                  As I understand it he server part of the embedded server is loaded
                                  dynamically - so the client may load but the server part will not load until
                                  a local connection is first requested.

                                  >
                                  > Our application has database access just about everywhere, but select
                                  > result sets are generally very small... at least for 99% of users, so
                                  > given the deployment flexibility, we'd probably just take a performance
                                  > hit if it exists, or try to rework some SQL.
                                  >
                                  > Regards,
                                  >
                                  > Peter Lee
                                  >
                                  > Alan McDonald wrote:
                                • Nando Dessena
                                  Alan, A Can I therefore distribute fbembed.dll (renamed to gds32.dll or A fbclient.dll - whichever I need) all the time - i.e. forget about the client A
                                  Message 16 of 22 , Dec 1, 2004
                                  • 0 Attachment
                                    Alan,

                                    A> Can I therefore distribute fbembed.dll (renamed to gds32.dll or
                                    A> fbclient.dll - whichever I need) all the time - i.e. forget about the client
                                    A> only lib (if distro size is not important)?

                                    you can but I'd rather make the application use fbembed.dll than
                                    renaming the library. If your data access layer supports it, that is.

                                    Ciao
                                    --
                                    Nando Dessena
                                    http://www.flamerobin.org
                                    ======================================================
                                    I support Firebird, I am a Firebird Foundation member!
                                    Join today at http://www.firebirdsql.org/ff/foundation
                                    ======================================================
                                  • Alan McDonald
                                    ... Why? What s the difference? Alan
                                    Message 17 of 22 , Dec 1, 2004
                                    • 0 Attachment
                                      > Alan,
                                      >
                                      > A> Can I therefore distribute fbembed.dll (renamed to gds32.dll or
                                      > A> fbclient.dll - whichever I need) all the time - i.e. forget
                                      > about the client
                                      > A> only lib (if distro size is not important)?
                                      >
                                      > you can but I'd rather make the application use fbembed.dll than
                                      > renaming the library. If your data access layer supports it, that is.
                                      >
                                      > Ciao
                                      > --
                                      > Nando Dessena


                                      Why? What's the difference?
                                      Alan
                                    • Nando Dessena
                                      Alan, ... A Why? What s the difference? Files, like everything, have names that help distingush them. Call a thing with a different name and it can be
                                      Message 18 of 22 , Dec 2, 2004
                                      • 0 Attachment
                                        Alan,

                                        >> you can but I'd rather make the application use fbembed.dll than
                                        >> renaming the library. If your data access layer supports it, that is.

                                        A> Why? What's the difference?

                                        Files, like everything, have names that help distingush them. Call a
                                        thing with a different name and it can be mistakenly thought as a
                                        different thing. ;-)

                                        Ciao
                                        --
                                        Nando Dessena
                                        http://www.flamerobin.org
                                        ======================================================
                                        I support Firebird, I am a Firebird Foundation member!
                                        Join today at http://www.firebirdsql.org/ff/foundation
                                        ======================================================
                                      Your message has been successfully submitted and would be delivered to recipients shortly.