TED] nombre de Chris
Travers
Enviado el: viernes, 29 de julio de 2005 2:23
Para: Gnanavel S
CC: Chris Travers; pgsql-performance@postgresql.org
Asunto: Re: [PERFORM] Left joining against two empty tables makes a
query
>
> Secondly, the project table has *never* had anything in it. So whe
Secondly, the project table has *never* had anything in it. So where
are these numbers coming from?
pg_statistics
I very much doubt that. I was unable to locate any rows in pg_statistic
where the pg_class.oid for either table matched any row's starelid.
Tom's argument that th
Gnanavel S wrote:
reindex the tables separately.
Reindexing should not affect this problem, anyway.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining co
On 7/28/05, Chris Travers <[EMAIL PROTECTED]> wrote:
Gnanavel S wrote:>>> vacuum & reindex the department and project table as the planner> expects there are 1060 rows but actually returning nothing.I guess I should have mentioned that I have been vacuuming and
reindexing at least once a week, and
Chris Travers <[EMAIL PROTECTED]> writes:
> Secondly, the project table has *never* had anything in it. So where
> are these numbers coming from?
The planner is designed to assume a certain minimum size (10 pages) when
it sees that a table is of zero physical length. The reason for this is
that
Gnanavel S wrote:
vacuum & reindex the department and project table as the planner
expects there are 1060 rows but actually returning nothing.
I guess I should have mentioned that I have been vacuuming and
reindexing at least once a week, and I did so just before running this test.
Normall
On 7/28/05, Chris Travers <[EMAIL PROTECTED]> wrote:
Hi all;I have a customer who currently uses an application which had becomeslow. After doing some digging, I found the slow query:SELECT c.accno, c.description, c.link, c.category, ac.project_id,p.projectnumber
,a.department_id, d.descri