RE: SQL/400

[Sandeep Potnis <potnis@xxxxxxxxx>]

Now I understand the dynamic bitmap index. Thanks guys. There's another
issue related to this. The interactive query that I was talking about was
generated by an OLAP tool that we are using for DSS. This means that

1. I don't have a lot of control over how the queries are generated.
2. Since clients have access to this dB through web to run adhoc queries,
there's a very little chance that I can foresee all the possible
selects/omits that they can specify.

Is there an optimum table size for such applications ? I can try a physical
partition (separate libraries)of the file, if its going to speed up queries.

FYI:We are going to upgrade to V4R4 from V4R2 in a month on an 8-way 650.

Thanks
Sandeep




------Original Message------
From: "Walden H. Leverich" <WaldenL@techsoftinc.com>
To: "'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com>
Sent: March 8, 2000 2:13:25 PM GMT
Subject: RE: SQL/400


Alexei,

However, as I understand it the view won't really speed things up much. The
view will give you the advantage of a pre-optimized access plan, but it
WON'T give you a pre-build access path. AFAIK, there is no SQL version of a
static select/omit access path. I would guess that the majority of the time
here is spent building a path, not determining a plan. The plan probably
takes several milliseconds, the rest of the time is the build.

Now that I've typed this I realize that Sandeep could determine the
selection the optimizer is doing and build a STATIC select/omit access path
with that selection outside of SQL. The optimizer should use it.

Sandeep, make sure you are doing your testing over a similarly sized files.
Different access plans are chosen depending on the number of records in a
file. It is ALWAYS fastest to tablescan a table with 100 rows, but in
production with 38,000,000 a tablescan is a killer.

-Walden


-----Original Message-----
From: pytel@us.ibm.com [mailto:pytel@us.ibm.com]
Sent: Tuesday, March 07, 2000 5:43 PM
To: MIDRANGE-L@midrange.com
Subject: RE: SQL/400


Building index from index is not the same as building index from table
data.
It normally involves doing preselection on underlying index.
If optimizer have chosen to build such index, it obviously decided that
this was the fastest way to get a result.
You cannot "pre-build" such index, so if you think this is a concern, try
to reformulate your query.

PS: as a second thought, you can try to build a view, if you can guess what
kind of preselection was done.
And then address your query to a view, not to original table.

Alexei Pytel


Sandeep Potnis <potnis@india.com> on 03/07/2000 03:20:24 PM

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com, "'MIDRANGE-L@midrange.com'"
<MIDRANGE-L@midrange.com>
cc:
Subject:  RE: SQL/400




I already have an index on that field. The issue is that its creating an
index on index dynamically. How can I avoid that ? Or should I try to avoid
that?


Appreciate your response.

Sandeep

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001


Build a logical over the file keyed by the date field.

> -----Original Message-----
> From:   Sandeep Potnis [SMTP:potnis@india.com]
> Sent:   Tuesday, March 07, 2000 9:18 AM
> To:     MIDRANGE-L@midrange.com
> Subject:     SQL/400
>
> Hi,
>
> I have a table(TableA) with 38 million rows in it. One of the columns is
> DATE type and I have an index(XDTIndex) on that column.
>
> When I run an interactive query with date selection I get an
informational
> message saying 'Building access path from XDTIndex'
>
> Can I avoid this by creating this access path in advance ? If so how?
>
> Thanks
>
> Sandeep
>
> ______________________________________________
> FREE Personalized Email at Mail.com
> Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---