I'd like to understand if it is possible to find a
solution to the problem that we have on ours DB in production.
I make an example simplified in order to explain
itself better:
We have 2 table :
TABLE vendor ( group TEXT, client
TEXT, vdr_venue_code CHAR(8), vdr_location_code
CHAR(8))
I'd like to understand if it is possible to find a solution to the problem
that we have on ours DB in production.
I make an example simplified in order to explain itself better:
We have 2 table :
TABLE vendor (
group TEXT,
client TEXT,
vdr_venue_code CHAR(8),
vdr_location_code CHAR(8)
)
I have 2 query that differ only for order by clause.
The time of execution of the two query is a lot of different.
1) explain analyze
select
tkstore.gruppo,tkstore.cassa,enabledcodes.sala,spettacoli.code
from
tkstore,enabledcodes,spettacoli
where
Alle 18:53, giovedì 11 marzo 2004, hai scritto:
> Paolo Tavalazzi <[EMAIL PROTECTED]> writes:
> > [ query plans after updating to 7.4.2 ]
>
> Okay, they're certainly a lot closer than before, so I think I was right
> that you were getting bitten somehow by the pg_stati
Alle 20:14, giovedì 11 marzo 2004, hai scritto:
> On Thu, Mar 11, 2004 at 09:43:57 +0100,
>
> Paolo Tavalazzi <[EMAIL PROTECTED]> wrote:
> > Alle 19:12, mercoledì 10 marzo 2004, hai scritto:
> > > On Wed, Mar 10, 2004 at 18:33:41 +0100,
> > >
> >
Alle 19:40, mercoledì 10 marzo 2004, hai scritto:
> Paolo Tavalazzi <[EMAIL PROTECTED]> writes:
> > I have applied the procedure for fixing pg_statistic as you had said,
> > but the result is the same!
>
> Hm. It could be a planner bug. Can you reproduce the misbeha
Alle 18:03, giovedì 11 marzo 2004, hai scritto:
> Paolo Tavalazzi <[EMAIL PROTECTED]> writes:
> > But the query plans are still various!!
>
> I think you made a copy-and-paste mistake, because the explain results
> you posted are exactly the same ...
>
>
Alle 16:54, mercoledì 10 marzo 2004, hai scritto:
> Paolo Tavalazzi <[EMAIL PROTECTED]> writes:
> > I have two query that they are different only for order of the tables
> > in FROM lclause , but give back different query plan :
>
> Hm, seems like the planner is ma
