| Subject | Re: [firebird-support] Firebird has MAJOR performance issues |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-08-14T14:53:52Z |
At 01:09 PM 14/08/2004 +0000, you wrote:
stored procedure as a persistent database structure or a temporary table.
It isn't. It's one row at a time output to a buffer. Once the row has
been fetched by the caller (in this case, the query engine) it is discarded
and the caller then asks for the next row. So go figure how this behaves
in an outer join and how you triggered off 9 million fetches for a join
that had 7000 actual matches.
Use a view for this structure, not a stored procedure.
/heLen
>Hello,..or too lengthy to answer...
>
>I'm wondering if I'm posting this to the correct group? It seems that
>either I'm asking a question that is too difficult to answer
>or this...or you just got it wrong.
>group does not want to annie up to the fact that Firebird does have
>major performance issues that the main stream databases (even MS
>Access) have figured out.
>I thought I included enough information to help this group diagnoseShort answer, you included enough information. Don't think of a selectable
>the problem, but I could be wrong.
stored procedure as a persistent database structure or a temporary table.
It isn't. It's one row at a time output to a buffer. Once the row has
been fetched by the caller (in this case, the query engine) it is discarded
and the caller then asks for the next row. So go figure how this behaves
in an outer join and how you triggered off 9 million fetches for a join
that had 7000 actual matches.
Use a view for this structure, not a stored procedure.
/heLen