On Sat, Oct 11, 2008 at 12:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> The sort-and-uniq doesn't care where the data came from. But if we have
> to feed it all rows of the table, as we do here, we're going to use a
> seqscan. An indexscan can never beat a seqscan for retrieving the whole
> tabl
"Jussi Pakkanen" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 9, 2008 at 6:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Try (3) COUNT(DISTINCT x) ... or any DISTINCT aggregate for that matter
>> ... is implemented by a sort-and-uniq step inside the aggregate function
>> itself. You can't see it in t
On Thu, Oct 9, 2008 at 6:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Given that PostgreSQL does the scan even with the huge seqscan
>> penalty, I can think of only two different causes:
>> 1) some sort of a bug in the query analyzer
>> 2) SELECT COUNT(DISTINCT x) for some reason requires informa
"Jussi Pakkanen" <[EMAIL PROTECTED]> writes:
> Given that PostgreSQL does the scan even with the huge seqscan
> penalty, I can think of only two different causes:
> 1) some sort of a bug in the query analyzer
> 2) SELECT COUNT(DISTINCT x) for some reason requires information that
> is not available
On Thu, Oct 9, 2008 at 3:05 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Jussi Pakkanen wrote:
>>
>> However when I try to count the amount of distinct codes, I get this:
>>
>>
>> EXPLAIN SELECT COUNT(DISTINCT code) FROM log;
>> QUERY PLAN
>>
>> -
Jussi Pakkanen wrote:
However when I try to count the amount of distinct codes, I get this:
EXPLAIN SELECT COUNT(DISTINCT code) FROM log;
QUERY PLAN
-
Aggregate (cost=100801488.
