Re: [HACKERS] Big IN() clauses etc : feature proposal

From: Markus Schaber <schabi(at)logix-tt(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal
Date: 2006-05-10 13:29:16
Message-ID: 4461EAAC.7030105@logix-tt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Hi, PFC,

PFC wrote:

> The problem is that you need a set-returning function to retrieve
> the values. SRFs don't have rowcount estimates, so the plans suck.

What about adding some way of rowcount estimation to SRFs, in the way of:

CREATE FUNCTION foo (para, meters) RETURNS SETOF bar AS
$$ ... function code ... $$ LANGUAGE plpgsql
ROWCOUNT_ESTIMATOR $$ ... estimation code ... $$ ;

Internally, this could create two functions, foo (para, meters) and
estimate_foo(para, meters) that are the same language and coupled
together (just like a SERIAL column and its sequence). The estimator
functions have an implicit return parameter of int8. Parameters may be
NULL when they are not known at query planning time.

What do you think about this idea?

The same scheme could be used to add a CPUCOST_ESTIMATOR to expensive
functions.

HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cristiano Duarte 2006-05-10 14:26:30 Re: BUG #2429: Explain does not report object's schema
Previous Message Bernd Helmle 2006-05-10 13:01:45 Re: BEGIN inside transaction should be an error

Browse pgsql-performance by date

  From Date Subject
Next Message Markus Schaber 2006-05-10 13:54:43 Re: [PERFORM] Arguments Pro/Contra Software Raid
Previous Message Florian Weimer 2006-05-10 12:44:06 Re: [PERFORM] Arguments Pro/Contra Software Raid