Subject | Change in processing full joins between IB5.6 and FB1.5 |
---|---|
Author | Chris Wallis |
Post date | 2005-10-26T04:26:58Z |
I have a stored procedure which worked well under IB5.6 but now runs for an
interminable time under FB1.5. The goal is to join all the lines of a new
'document' with a previous document so that changes can be calculated,
including the recognition of document lines that the previous and current
document do not have in common. I'm using a self-join on a table. So the
problematic SQL looks like this:
select
h0.HSD_DOC_ID,
h0.SEC_ID,
h0.HLDG_SHARES,
h0.HLDG_MKT_VALUE,
h0.HLDG_PAR_VALUE,
h0.HLDG_SEQNO,
h1.HSD_DOC_ID,
h1.SEC_ID,
h1.HLDG_SHARES,
h1.HLDG_MKT_VALUE,
h1.HLDG_PAR_VALUE,
h1.HLDG_SEQNO
from
holdings h0 full join
holdings h1 on h0.sec_id=h1.sec_id
where
(
h0.hsd_doc_id=:IPREV_DOC_ID or
h0.hsd_doc_id is null
)
and
(
h1.hsd_doc_id=:ADOCID
)
It seems like under FB1.5 the whole cross-product of the join is being
formed and then the 'where' conditions are applied, which is probably the
correct implementation of the SQL standard, but it worked well under IB5.6
and is now unusable for performance reasons when FB1.5. Can anyone tell me
how the SQL processing has changed between IB5.6 and FB1.5 relative to this
query? This is in a stored procedure and I'm already starting to think of
alternatives to get the same result, but any implementation suggestions are
welcome.
interminable time under FB1.5. The goal is to join all the lines of a new
'document' with a previous document so that changes can be calculated,
including the recognition of document lines that the previous and current
document do not have in common. I'm using a self-join on a table. So the
problematic SQL looks like this:
select
h0.HSD_DOC_ID,
h0.SEC_ID,
h0.HLDG_SHARES,
h0.HLDG_MKT_VALUE,
h0.HLDG_PAR_VALUE,
h0.HLDG_SEQNO,
h1.HSD_DOC_ID,
h1.SEC_ID,
h1.HLDG_SHARES,
h1.HLDG_MKT_VALUE,
h1.HLDG_PAR_VALUE,
h1.HLDG_SEQNO
from
holdings h0 full join
holdings h1 on h0.sec_id=h1.sec_id
where
(
h0.hsd_doc_id=:IPREV_DOC_ID or
h0.hsd_doc_id is null
)
and
(
h1.hsd_doc_id=:ADOCID
)
It seems like under FB1.5 the whole cross-product of the join is being
formed and then the 'where' conditions are applied, which is probably the
correct implementation of the SQL standard, but it worked well under IB5.6
and is now unusable for performance reasons when FB1.5. Can anyone tell me
how the SQL processing has changed between IB5.6 and FB1.5 relative to this
query? This is in a stored procedure and I'm already starting to think of
alternatives to get the same result, but any implementation suggestions are
welcome.