Re: [PERFORM] Cursors performance
От | Bill Chandler |
---|---|
Тема | Re: [PERFORM] Cursors performance |
Дата | |
Msg-id | 20040713161346.62000.qmail@web51404.mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] Cursors performance (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: [PERFORM] Cursors performance
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: