Re: [HACKERS] GUC parameter cursors_tuple_fraction

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, "Hell, Robert" <Robert(dot)Hell(at)fabasoft(dot)com>, pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] GUC parameter cursors_tuple_fraction
Date: 2008-05-02 17:35:27
Message-ID: 1209749727.4264.169.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> > Simon Riggs wrote:
> >> * We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
> >> "Don't want hints". If that's what we really think, then this patch must
> >> surely be rejected because its a hint... That isn't my view. I *now*
> >> think we do need hints of various kinds.
>
> > cursors_tuple_fraction or OPTIMIZE FOR xxx ROWS isn't the kind of hints
> > we've said "no" to in the past.
>
> More to the point, I think what we've generally meant by "hints" is
> nonstandard decoration on individual SQL commands (either explicit
> syntax or one of those interpret-some-comments kluges).

Yes, that is definitely an Oracle compatibility thought.

> Simon is
> reading the policy in such a way that it would forbid all the planner
> cost parameters, which is surely not what is intended.

So we're allowed to influence the behaviour of the planner, but just not
by touching the individual statements. OK.

Can we allow a statement like

SET index_weighting = '{{my_index, 0.1},{another_index, 0.5}}'

That would allow us to tell a specific SQL statement that it should use
a cost weighting of 0.1 * normal cost for the "my_index" index (etc).
SET enable_seqscan = off; is a blunt instrument that can sometimes
achieve the same thing, but insufficiently exact to be really useful.
Many people use that (Sun, in their first published PostgreSQL
benchmark...)

We/I want to make the planner even better, but the above is roughly what
people want while they're waiting for us to get the planner right.

> I see this as being basically another cost parameter, and as such
> I don't think it needs more documentation than any of those have.
> (Now admittedly you could argue that they could all use a ton more
> documentation than they now have, but it's not reasonable to insist
> on just this one meeting a different standard.)

OK, seems fair.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-05-02 17:41:48 Re: GUC parameter cursors_tuple_fraction
Previous Message Greg Sabino Mullane 2008-05-02 17:26:14 Re: Protection from SQL injection

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2008-05-02 17:41:48 Re: GUC parameter cursors_tuple_fraction
Previous Message Joshua D. Drake 2008-05-02 16:28:59 Re: configure option for XLOG_BLCKSZ