[PERFORM] What about utility to calculate planner cost constants?

2005-03-21 Thread Tambet Matiisen
I was following the cpu_tuple_cost thread and wondering, if it could be possible to make PQA style utility to calculate configuration-specific values for planner cost constants. It could make use of output of log_(statement|parser|planner|executor)_stats, tough I'm not sure if the output contains

Re: [PERFORM] column name is LIMIT

2005-03-21 Thread Jan Wieck
On 3/14/2005 4:26 AM, Qingqing Zhou wrote: So is it to make SQL parser context-sensitive - say the parser will understand that in statement SELECT * from LIMIT, LIMIT is just a table name, instead of keyword? More or less, yes. To use a reserved keyword as an identifier (table or column name), it

Re: [PERFORM] column name is LIMIT

2005-03-21 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: There is a builtin function quote_ident() in PostgreSQL that is supposed to return a properly quoted string allowed as an identifier for whatever name is passed in. But it fails to do so for all lower case names that are reserved keywords. Not any more

Re: [PERFORM] What about utility to calculate planner cost constants?

2005-03-21 Thread Josh Berkus
Tambet, I was following the cpu_tuple_cost thread and wondering, if it could be possible to make PQA style utility to calculate configuration-specific values for planner cost constants. It could make use of output of log_(statement|parser|planner|executor)_stats, tough I'm not sure if the

Re: [PERFORM] What needs to be done for real Partitioning?

2005-03-21 Thread Josh Berkus
Stacy, Luckily they that had the chance to work with a truly fantastic DBA (the author of an Oracle Press performance tuning book even) before they could switch back. He convinced them to make some of their indexes global. Performance dramatically improved (compared with both the

Re: [PERFORM] What about utility to calculate planner cost constants?

2005-03-21 Thread Thomas F.O'Connell
If by not practical you mean, no one has implemented a multivariable testing approach, I'll agree with you. But multivariable testing is definitely a valid statistical approach to solving just such problems. -tfo -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC

Re: [PERFORM] What needs to be done for real Partitioning?

2005-03-21 Thread Jim C. Nasby
On Mon, Mar 21, 2005 at 09:55:03AM -0800, Josh Berkus wrote: Stacy, Luckily they that had the chance to work with a truly fantastic DBA (the author of an Oracle Press performance tuning book even) before they could switch back. He convinced them to make some of their indexes global.

Re: [PERFORM] What needs to be done for real Partitioning?

2005-03-21 Thread Jim C. Nasby
On Sat, Mar 19, 2005 at 07:05:53PM -0500, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: We probably also need multi-table indexes. As Josh says, that seems antithetical to the main point of partitioning, which is to be able to rapidly remove (and add) partitions of a table. If

Re: [PERFORM] What about utility to calculate planner cost constants?

2005-03-21 Thread Josh Berkus
Thomas, If by not practical you mean, no one has implemented a multivariable testing approach, I'll agree with you. But multivariable testing is definitely a valid statistical approach to solving just such problems. Well, not practical as in: would take either $10 million in equipment or

Re: [PERFORM] What about utility to calculate planner cost constants?

2005-03-21 Thread Greg Stark
Josh Berkus josh@agliodbs.com writes: Otherwise it could just collect statements, run EXPLAIN ANALYZE for all of them and then play with planner cost constants to get the estimated values as close as possible to actual values. Something like Goal Seek in Excel, if you pardon my reference