From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Hell, Robert" <Robert(dot)Hell(at)fabasoft(dot)com>, <pgsql-patches(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GUC parameter cursors_tuple_fraction |
Date: | 2008-05-02 15:17:14 |
Message-ID: | 481B307A.4010308@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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. We don't want hints that work-around
planner deficiencies, for example where we get the row count of a node
completely wrong. This is different. This is about telling how the
application is going to use the result set. It's relevant even assuming
that the planner got the estimates spot on. Which plan is the best
depends on whether the application can start processing the data as it
comes in, or whether it's loading it all in memory first, for example.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-02 16:01:37 | Re: [HACKERS] GUC parameter cursors_tuple_fraction |
Previous Message | Simon Riggs | 2008-05-02 15:03:32 | Re: GUC parameter cursors_tuple_fraction |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Wong | 2008-05-02 15:42:42 | Re: configure option for XLOG_BLCKSZ |
Previous Message | Simon Riggs | 2008-05-02 15:03:32 | Re: GUC parameter cursors_tuple_fraction |