On 3/20/24 09:51, Celia McInnis wrote:
The view is being used in some web query software that multiple people will be accessing and the contents of the view depend on what the person is querying, so I think that temporary views or tables are a good idea. I change to non-temporary views or tables (in a test version of the software which is not web-crawl-able) when I'm trying to debug things, and I guess I have to be careful to clean those up when I switch back to the temporary tables/views.
Why change behavior for the tests? Seems that sort of negates the value of the testing.
Have you run EXPLAIN ANALYZE on the problem query?
On Wed, Mar 20, 2024 at 11:46 AM Adrian Klaver <adrian.klaver@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>> wrote:On 3/20/24 08:39, Celia McInnis wrote: > Ok, thanks - so I guess that means that if there is both a temporary and > a non temporary view called "tempvie", > > DROP VIEW tempview; > > will remove the 1st tempview found, which with my path is the temporary > one. Is there some reason why it then took 7 minutes to select from the > non-temporary view tempview after I dropped the temporary view tempview? > > I have sometimes had some very long query times when running query > software, and maybe they are resulting from my switching between > temporary and non-temporary views of the same name while debugging. If > so, is there something I should be doing to clean up any temporary > messes I am creating? What is the purpose of the temp view over the the regular view process? How do they differ in data? Is all the above happening in one session? Have you run EXPLAIN ANALYZE on the select from the regular view? > > Thanks, > Celia McInnis >-- Adrian Klaveradrian.klaver@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>
-- Adrian Klaver adrian.klaver@xxxxxxxxxxx
