On Monday 21 May 2007 11:34, Richard Huxton wrote:
> Chuck D. wrote:
>
> The only thing I can think of is that the CLUSTERing on city.country_id
> makes the system think it'll be cheaper to seq-scan the whole table.
>
> I take it you have got 2 million rows in "city&q
On Monday 21 May 2007 05:40, Richard Huxton wrote:
> Chuck D. wrote:
>
> Any good reason why country_id is NULLable?
It has been a while since I imported the data so it took some time to examine
it but here is what I found.
In the original data, some cities do not have coutries. St
On Monday 21 May 2007 03:14, Josh Berkus wrote:
> Chuck,
>
> Can we see the plan?
>
> --Josh
>
Sorry Josh, I guess I could have just used EXPLAIN instead of EXPLAIN
ANALYZE.
# explain
SELECT country_id, country_name
FROM geo.country
WHERE country_id IN
(select country_id FROM geo.city)
;
Hi all,
I know we've covered this before but I'm having trouble with it today.
I have some geographic data in tables that I'm working with. I have a
country, state and city table. I was selecting the country_name out of the
country table but discovered that some countries (like Antarctica) didn
On Tuesday 13 February 2007 14:51, Tom Lane wrote:
> "Chuck D." <[EMAIL PROTECTED]> writes:
> > It is still using that sequence scan on the view after the APPEND for the
> > us_city and world_city table. Any reason why the view won't use the
> > indexes
On Tuesday 13 February 2007 13:16, Merlin Moncure wrote:
>
> use 'union all' instead of union. union without all has an implied
> sort and duplicate removal step that has to be resolved, materializing
> the view, before you can join to it.
>
Thanks for that Merlin, I forgot about using ALL. That
Hi folks,
I don't know if this is an SQL or PERFORMANCE list problem but I wanted to
check here first. I've seen this discussed on the list before but I'm still
not sure of the solution. Maybe my query is just structured wrong.
I recently visited an old project of mine that has a 'city', 'sta
