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@aklaver.com <mailto:adrian.klaver@aklaver.com>> 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 Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
--
Adrian Klaver
adrian.klaver@aklaver.com