Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 11 to 14 of 14 total |
VIEWs running slower than queries in 2.02b10 |
Mon, Mar 16 2009 3:28 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Hedley,
<< Yes, I now understand how EDB handles VIEWs. Please forgive my ignorance in this matter Tim. >> BTW, I didn't mean for that to sound snotty, so my apologies if that's the way it came across. I was writing "conversationally", and sometimes it's hard to ask a question like that without it looking odd when read. << Do you mean "this is how they work in EDB"? >> Yes, of course. << Although I don't have anywhere near your experience, with other engines I've used (PGSQL, MySQL, SQL Server), I have never noticed that using a VIEW + WHERE clause has come with any kind of performance hit like EDB does. >> It's always possible. Each database engine is designed differently. EDB is designed to implement views like tables, so that they are opened once and stay open until they are closed. This means that as long as they are opened, they will not need to be executed again and will materialize immediately. You'll see this with greater effect once we allow you to do something similar to the KeepTablesOpen setting. << I am curious as to when you would recommend the use of VIEWs in EDB? (The only time I can think of is if you're executing the exact same SELECT SQL over-and-over and if you hold on to the prepared VIEW query?) >> See my above paragraph. << Would that help the scenario when you're JOINing a query to one or more VIEWs? (I do that quite a lot and it's still a bit slow). >> Only in the same sense as any other query that references views, i.e. the JOINs don't play any part in the equation. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Mar 16 2009 4:01 PM | Permanent Link |
"Hedley Muscroft" | Thanks for the info Tim.
>> BTW, I didn't mean for that to sound snotty, so my apologies >> if that's the way it came across. No problem! I'm sure I speak for everyone in this newsgroup in saying that we really appreciate your help & support, and even if you did get a little snotty at times, we wouldn't blame you! >> EDB is designed to implement views like tables, >> so that they are opened once and stay open until >> they are closed. This means that as long as they >> are opened, they will not need to be executed again >> and will materialize immediately. You'll see this with >> greater effect once we allow you to do something similar >> to the KeepTablesOpen setting. Hmmm... I see how that will work in Delphi, but ADO.NET is designed around 'disconnected' datasets i.e. open connection - get data - close connection / open connection - write date - close connection. How do we keep a VIEW (or a TABLE for that matter) open in ADO.NET? |
Thu, Mar 19 2009 1:25 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Hedley,
<< Hmmm... I see how that will work in Delphi, but ADO.NET is designed around 'disconnected' datasets i.e. open connection - get data - close connection / open connection - write date - close connection. >> Yes, and we already discussed this - you're going to have to keep the connection open if you want decent performance with the EDB Data Provider. That is the only requirement for the KeepTablesOpen attribute/property to do its job. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Mar 19 2009 5:15 PM | Permanent Link |
"Hedley Muscroft" | OK - thanks.
|
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |