[HACKERS] about how to un-describe from pgsql-hackers

2006-09-01 Thread zhou bo
Hi, guys 

  i have already send a undescribe request to [EMAIL PROTECTED], 
but i receive a reject reply. 


  who can tell me how to undescribe it ?

thanks.





From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: zhou bo [EMAIL PROTECTED]
Subject: Majordomo results: unsubscribe  pgsql-hackers
Date: Fri, 01 Sep 2006 08:27:30 -0300


 unsubscribe  pgsql-hackers
 The unsubscribe command did not succeed.

 No e-mail addresses matching
   zhou bo [EMAIL PROTECTED]
 are subscribed to the pgsql-hackers mailing list.


Valid commands processed: 1
0 succeeded, 0 stalled, and 1 failed.


Use the following command:
  sessioninfo 15453d661d9e06ac044850d282fbe5935edba4bd
to see technical information about this session.





---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] Prepared statements considered harmful

2006-08-31 Thread zhou bo
hello everyone , 



   i has been add to you guys' mail list by accident, i don't how to 
refuse to receive your mails, would you please help me to remove my mail 
address form mail group [EMAIL PROTECTED]


   i appreciatewhat you will do for me. (my mail address: 
[EMAIL PROTECTED])



thanks .









From: Csaba Nagy [EMAIL PROTECTED]
To: Peter Eisentraut [EMAIL PROTECTED]
CC: postgres hackers pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Prepared statements considered harmful
Date: Thu, 31 Aug 2006 14:52:05 +0200

On Thu, 2006-08-31 at 14:32, Peter Eisentraut wrote:
 Am Donnerstag, 31. August 2006 14:11 schrieb Csaba Nagy:
  How about prepared means really prepared... in the sense of 

parsed,
  analyzed all sensible plans, and save a meta-plan which based on 

current

  statistics and parameter values chooses one of the considered (and
  cached) plans ?

 I don't think this could solve one particularly frequent problem which 

is that
 pattern matching queries don't get along with prepared plans if the 

search

 pattern isn't known at planning time.

Why not ? I specifically said you would prepare a few sensible plans
based on statistics/expected variations of the statistics, and parameter
value ranges which would trigger different plans.

So for the like query case you could save 2 plans, one for the indexable
case, one for the not indexable case. Then at runtime you choose the
proper one based on the pattern value. The meta-plan I mentioned would
be a collection of plans with rules to choose the right one at run time
based on parameter values and perhaps the current statistics.

This of course would need a lot more preparation time than just prepare
one plan, but that's why you want to do it upfront and then cache the
results. A central plan repository mentioned in other posts would fit
nicely here... and you could use prepared plans for non-parameterized
queries too by simply considering the constants as parameters, to
increase the chances for a prepared plan reuse - this of course for
complex enough queries.

Cheers,
Csaba.


---(end of broadcast)---
TIP 6: explain analyze is your friend




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings