Re: [HACKERS] Big IN() clauses etc : feature proposal - Mailing list pgsql-performance

From Nis Jorgensen
Subject Re: [HACKERS] Big IN() clauses etc : feature proposal
Date
Msg-id 446206FF.7050603@superlativ.dk
Whole thread Raw
In response to Re: [HACKERS] Big IN() clauses etc : feature proposal  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: [HACKERS] Big IN() clauses etc : feature proposal  (Markus Schaber <schabi@logix-tt.com>)
List pgsql-performance
Martijn van Oosterhout wrote:
> On Wed, May 10, 2006 at 04:38:31PM +0200, PFC wrote:
>>     You need to do some processing to know how many rows the function
>>     would  return.
>>     Often, this processing will be repeated in the function itself.
>>     Sometimes it's very simple (ie. the function will RETURN NEXT each
>> element in an array, you know the array length...)
>>     Sometimes, for functions returning few rows, it might be faster to
>> compute the entire result set in the cost estimator.
>
> I think the best would probably be to assign a constant. An SRF will
> generally return between one of 1-10, 10-100, 100-1000, etc. You don't
> need exact number, you just need to get within an order of magnitude
> and a constant will work fine for that.
>
> How many functions sometimes return one and sometimes a million rows?

It will probably be quite common for the number to depend on the number
of rows in other tables. Even if this is fairly constant within one db
(some assumption), it is likely to be different in others using the same
function definition. Perhaps a better solution would be to cache the
result of the estimator function.

/Nis



pgsql-performance by date:

Previous
From:
Date:
Subject: Re: in memory views
Next
From: Markus Schaber
Date:
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal