Re: [HACKERS] A caveat of partitioning tables in the document

2012-08-27 Thread Kasahara Tatsuhito
2012/8/23 Tom Lane :
> Fujii Masao  writes:
>> On Wed, Aug 22, 2012 at 12:59 AM, Kasahara Tatsuhito
>>  wrote:
>>> The latest document (doc/src/sgml/ddl.sgml) says
>>> ===
>>> 2974
>>> 2975 
>>> 2976  
>>> 2977   Constraint exclusion only works when the query's 
>>> WHERE
>>> 2978   clause contains constants.  A parameterized query will not be
>>> 2979   optimized, since the planner cannot know which partitions the
>>> 2980   parameter value might select at run time.  For the same reason,
>>> 2981   stable functions such as 
>>> CURRENT_DATE
>>> 2982   must be avoided.
>>> 2983  
>>> 2984 >> ===
>>> but in my understanding, this problem will be solved on 9.2 (with
>>> parameterized plans).
>>>
>>> Or some issues still remain ?
>
>> At least this limitation "A parameterized query will not be optimized,
>> since the planner cannot know which partitions the parameter value
>> might select at run time." has been solved unless I'm missing something.
>> So we should just get rid of that sentence from the document.
>
> Yes, I think we can take that out now.  The issue with stable functions
> still remains though.

Thanks for your replay.

I see we can remove the topic from the doc except a issue with stable functions.

Best regards,

-- 
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] A caveat of partitioning tables in the document

2012-08-21 Thread Kasahara Tatsuhito
Hi.

The latest document (doc/src/sgml/ddl.sgml) says
===
2974
2975 
2976  
2977   Constraint exclusion only works when the query's WHERE
2978   clause contains constants.  A parameterized query will not be
2979   optimized, since the planner cannot know which partitions the
2980   parameter value might select at run time.  For the same reason,
2981   stable functions such as CURRENT_DATE
2982   must be avoided.
2983  
2984 http://www.postgresql.org/mailpref/pgsql-hackers