Search Postgresql Archives

Re: [PGSQL v8.2.5] Similar queries behave differently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il Thursday 25 October 2007 13:20:40 Gregory Stark ha scritto:
> "Gregory Stark" <stark@xxxxxxxxxxxxxxxx> writes:
> > "Reg Me Please" <regmeplease@xxxxxxxxx> writes:
> >>                ->  Seq Scan on tt_elem  (cost=0.00..29.40 rows=1940
> >> width=8) (actual time=0.012..0.013 rows=1 loops=1)
> >
> > The discrepancy etween the estimated rows and actual rows makes me think
> > you've not analyzed this table in a long time. It's probably best to
> > analyze the whole database to have a consistent set of statistics and to
> > catch any other old table stats.
> >
> > There could be other misestimations based due to Postgres limitations but
> > first fix the out of date stats and re-post both plans.
>
> Actually it's pretty clear there are some other bad estimations as well.
> You should send along the view definition too.
>
> And I would recommend you try it with a normal JOIN ON/USING instead of the
> NATURAL JOIN. It's possible it's joining on some unexpected columns --
> though that doesn't really look like it's the case here.

I'm not sure whether my previous message has reached the list.

In any case, the tables have been created with a pg_restore and, thus,
not much stats should be available not out-of-date ones.

I'd actually like to better understand how to compose queries (and indexes)
in order to make them appealing to the query planner.

--------
Oggetto: Re: [PGSQL v8.2.5] Similar queries behave differently
Data: giovedì 25 ottobre 2007
Da: Reg Me Please <regmeplease@xxxxxxxxx>
A: pgsql-general@xxxxxxxxxxxxxx

Hai all again.

Maybe I've solved the problem, but would like to have some hint on "why".

In the second query I've substituted the last join (natural join tt_rice)
with an additional "where condition". I can do this as I am sure that
the tt_rice table will always contain just one row with one field.

The main difference with the first query is that in the first case the
single row with a single field is a "bigint", while in the second one it
is "text".

Otherwise the two queries are almost identical, apart the number of result
rows and the size of the joined tables.

Is there any deeper tutorial on how to read (and understand) the explain
analyze output?

Many thanks again.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
       message can get through to the mailing list cleanly


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux