Re: Functionscan estimates

From: PFC
Subject: Re: Functionscan estimates
Date: ,
Msg-id: op.soyp6wpeth1vuj@localhost
(view: Whole thread, Raw)
In response to: Re: Functionscan estimates  (Tom Lane)
List: pgsql-performance

Tree view

Functionscan estimates  (Josh Berkus, )
 Re: Functionscan estimates  (Michael Fuhr, )
  Re: Functionscan estimates  (Alvaro Herrera, )
   Re: Functionscan estimates  (Josh Berkus, )
    Re: Functionscan estimates  (Alvaro Herrera, )
     Re: Functionscan estimates  (Tom Lane, )
      Re: Functionscan estimates  (PFC, )
      Re: Functionscan estimates  ("Jim C. Nasby", )
       Re: Functionscan estimates  (Tom Lane, )
        Re: Functionscan estimates  (Neil Conway, )
         Re: Functionscan estimates  (Josh Berkus, )
      Re: Functionscan estimates  (Neil Conway, )
    Re: Functionscan estimates  (PFC, )

> But with all due respect to Joe, I think the reason that stuff got
> trimmed is that it didn't work very well.  In most cases it's
> *hard* to write an estimator for a SRF.  Let's see you produce
> one for dblink() for instance ...

    Good one...
    Well in some cases it'll be impossible, but suppose I have a function
get_id_for_something() which just grabs an ID using dblink, then I know it
returns one row, and pg would be interested in that information too !


pgsql-performance by date:

From: Tom Lane
Date:
Subject: Re: Functionscan estimates
From: tv@fuzzy.cz
Date:
Subject: performance - triggers, row existence etc.