"John D. Burger" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Also I'd suggest trying
>> select year from [table] group by year
>> which is capable of using a hash aggregation approach; that will likely
>> beat either of these plans.
> Just out of curiosity, why doesn't the planner consider th
Tom Lane wrote:
Also I'd suggest trying
select year from [table] group by year
which is capable of using a hash aggregation approach; that will likely
beat either of these plans.
Just out of curiosity, why doesn't the planner consider the same plan
for the OP's original query:
s
Tom,
Thanks for the advice. I realize that I have little understanding of
index usage in PostgreSQL - I'm doing my best to improve this. Below is
another comparison of the 'distinct' and 'group by' queries from the
same table with seqscan set to on and off. I does look like the group
by works b
Mike Leahy <[EMAIL PROTECTED]> writes:
> ... When I try to get the distinct number of
> years from these tables, it does a sequential scan to get two unique
> values from the "year" column in the *_edu table, but it uses an index
> scan to get a single unique value from the "year" column from the *
Hello list,
I've been having a bit of difficulty getting Postgres to use indexes on
some large tables that I have. Included below are the results from
'explain analyze' for two queries that should get the unique years of
data that are available from two different tables (tbl_ind_schools_edu
and t
