Hello mailing list,
I have a performance problem with my postgres 8.4.4 database. The query is
the following:
SELECT count(*) AS count_all FROM "plan_events" WHERE (f_plan_event_acl(17,
plan_events.id))
QUERY PLAN
--
On Wed, Jul 14, 2010 at 09:58:10PM +1000, Anders ??stergaard Jensen wrote:
> Hello mailing list,
>
> I have a performance problem with my postgres 8.4.4 database. The query is
> the following:
>
> SELECT count(*) AS count_all FROM "plan_events" WHERE (f_plan_event_acl(17,
> plan_events.id))
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Campbell, Lance wrote:
> I want to subtract to dates to know the number of days different.
>
>
>
> Example:
>
> 01/02/2010 - 01/01/2010 = 1 day
>
> 08/01/2010 - 07/31/2010 = 1 day
>
>
>
> How do I do this?
>
Others have posted SQL answers to t
On Wed, Jul 14, 2010 at 02:30:29PM +0200, Reinoud van Leeuwen wrote:
> On Wed, Jul 14, 2010 at 09:58:10PM +1000, Anders ??stergaard Jensen wrote:
> > SELECT count(*) AS count_all FROM "plan_events" WHERE (f_plan_event_acl(17,
> > plan_events.id))
> >
> >
On Wed, Jul 14, 2010 at 07:30:39AM -0600, Joshua Tolley wrote:
> > Have you tried 'select count (1)..."?
>
> If this helps at all, it's unlikely to help much. I remember having seen
> discussion somewhere that there's an optimization such that count(*) and
> count(1) do the same thing anyway, but
Jean-David Beyer wrote on 14.07.2010 14:37:
My dates are of the form -mm-dd and such.
Storing a date as a string is never a good idea.
And I want to do things like adding or subtracting days, months, or years to it
or from it.
Also the logical comparisons.
Which is all a piece of cake wh
The first statement of the function
> : select into user *
> from users where id = uid;
appears to be a useless drag, as I don't see the user record referred
to anywhere else in the function. There appears to be other
unnecessary statements. For
In retrospect, it's a big assumption whether f_project_acl() or
f_customer_acl() always return TRUE. If they can return FALSE, you
probably want to replace the statements inside the FOR..LOOP with
>IF plan_record.project_id IS NOT NULL THEN
>IF f_project_ac
Thomas Kellerer wrote:
> Jean-David Beyer wrote on 14.07.2010 14:37:
>> My dates are of the form -mm-dd and such.
> Storing a date as a string is never a good idea.
I started this long ago, when postgreSQL did not really work very well
(1998?). One version of it would not do views, and another
Hi all,
Thank you so much for your kind replies. It has all been a great help.
I tried the SELECT COUNT(1) but that didn't yield any improvement, sorry.
Doing the index on f_plan_event_acl( ... ) wont work, as the parameters are
frequently shifted (the second parameter denotes the id of a user i
Hi all,
Thank you so much for your kind replies. It has all been a great help.
I tried the SELECT COUNT(1) but that didn't yield any improvement, sorry.
Doing the index on f_plan_event_acl( ... ) wont work, as the parameters are
frequently shifted (the second parameter denotes the id of a user i
It appears that the acl functions use more SELECTs than necessary. For
f_customer_acl(uid
integer, cid integer), I might use:
PERFORM 1 FROM customers JOIN users USING (org_id) WHERE customer_id =
cid and user_id = uid;
RETURN FOUND;
This still requires one call to f_customer_acl() (and there
12 matches
Mail list logo
