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
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
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
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
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
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
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.
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
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
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
10 matches
Mail list logo