All,
Looks like I may have beaten this one to death. May
have to chalk it up to a limitation for now due to
deadlines and revisit it later.
One final clue before I go: if I change my wildcard to
'NEPOOL%' from 'NEPOOL%REAL%' my query completes much
faster. Of course this makes sense since it's much
easier to search a string for a prefix than it is to
do a complex regular expression match. I just didn't
expect it to be orders of magnitude difference.
The table containing the string being searched is only
7500 rows but I am joining it with a table with
2.5 million rows. So maybe there's something I can do
to do the wildcard search on the smaller table first
then do the join.
Ok, thanks again to all who responded. Really
appreciate the tips on logging statements and
duration, etc.
regards,
Bill
--- Kris Jurka <books@ejurka.com> wrote:
>
>
> On Mon, 12 Jul 2004, Barry Lind wrote:
>
> > Bill,
> >
> > I suspect that this is an artifact of using server
> side prepared
> > statements. When testing this via psql you will
> be forming sql like:
>
> I don't think so. The 7.4 driver can use either
> cursors or server
> prepared statements, not both. He's definitely
> using cursors, so I server
> prepared statements don't come into the mix here.
>
> Kris Jurka
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail