Re: Hashagg planning bug (8.0.1) - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: Hashagg planning bug (8.0.1)
Date
Msg-id 1115742105.6888.87.camel@home
Whole thread Raw
In response to Re: Hashagg planning bug (8.0.1)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hashagg planning bug (8.0.1)
List pgsql-hackers
On Tue, 2005-05-10 at 12:11 -0400, Tom Lane wrote:
> Rod Taylor <pg@rbt.ca> writes:
> > It would seem that the planner does not take into account whether the
> > datatypes involved have the capability to use hash aggregates or not.
> 
> > sdb=# explain select query_start, current_query    from pg_locks join stat_activity on pid = procpid where granted
=true and transaction in (select transaction from pg_locks where granted = false);
 
> > ERROR:  could not find hash function for hash operator 716373
> 
> What's stat_activity?  I thought you meant pg_stat_activity, but that
> works fine here.

Oh, stat_activity is a view which removes idle connections from
displaying and allows non-privileged users to see everything that's
going on within the DB.

CREATE OR REPLACE FUNCTION stat_activity() RETURNS setof pg_stat_activity SECURITY DEFINER AS 'select * from
pg_stat_activity;' language sql;
 

CREATE OR REPLACE VIEW stat_activity ASSELECT stat_activity.procpid, stat_activity.usename,
stat_activity.query_start::timestamp(0) without time zone AS
query_start, stat_activity.current_query  FROM stat_activity() WHERE stat_activity.current_query <> '<IDLE>'::text;

-- 



pgsql-hackers by date:

Previous
From: Nicolai Petri
Date:
Subject: Adding callback support.
Next
From: Tom Lane
Date:
Subject: Re: Hashagg planning bug (8.0.1)