Aaron Bono wrote:
> Looks like a vacuum analyze did the trick. Performance is beautiful now. I
> should have tried that earlier.
>
> I thought I had the auto vacuum turned on (PostgreSQL 8.1) but I guess it
> doesn't do analyze?
>
> Anyway, I will schedule a vacuum analyze nightly - it is low
On 4/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Aaron Bono" <[EMAIL PROTECTED]> writes:
> The biggest problem I notice is when I add a join from a child table
> (zip_city) to a parent table (zip). I have filtered the child table
down to
> about 650 records but when I add the join to the parent
"Aaron Bono" <[EMAIL PROTECTED]> writes:
> The biggest problem I notice is when I add a join from a child table
> (zip_city) to a parent table (zip). I have filtered the child table down to
> about 650 records but when I add the join to the parent which has over
> 800,000 records, performance tank
On 4/25/07, Richard Huxton <[EMAIL PROTECTED]> wrote:
Aaron Bono wrote:
> Performance tanks with this query - it takes over 120 seconds (that is
> where
> I set the timeout).
> BTW, on our Linux box the full query we run (which adds 3 more tables on
> the
> whole operation along with more filte
Aaron Bono wrote:
Performance tanks with this query - it takes over 120 seconds (that is
where
I set the timeout).
BTW, on our Linux box the full query we run (which adds 3 more tables on
the
whole operation along with more filtering on the zip table) finishes in
under 10 seconds. Problem i
I have a database with the following tables:
zip {
zip_id bigserial,
zip_cd varchar(6) -- this is indexed
}
city {
city_id bigserial,
city_name varchar(50)
}
zip_city {
city_id bigint (FK to city table),
zip_id bigint (FK to zip table),
longitude numeric,
latitude numeri
