I'm interested in the response time instead of the quality of it, that is,
if this response is (or not) a best plan. Thus, my interest on the response
time is to compare the GEQO algorithm with other solutions for optimization
of queries, more specificaly when there are 12 or more tables evolved.
A
On Wed, 2008-05-28 at 13:13 -0300, Tarcizio Bini wrote:
> Of course, the geqo_threshold can be changed so that the geqo be
> performed in queries that have less than 12 tables. However, we aim to
> test the GEQO algorithm in conditions where the standard algorithm
> (dynamic programming) has a hi
Hi,
Of course, the geqo_threshold can be changed so that the geqo be performed
in queries that have less than 12 tables. However, we aim to test the GEQO
algorithm in conditions where the standard algorithm (dynamic programming)
has a high cost to calculate the query plan.
--
Tarcizio Bini
2008
[EMAIL PROTECTED] writes:
> I'm using the TPC-H Benchmark for testing of performance in PostgreSQL.
> But it is composed of only 8 tables, which is not enough to call the GEQO
> algorithm.
See
http://www.postgresql.org/docs/8.3/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO
particular
Hi all,
I'm using the TPC-H Benchmark for testing of performance in PostgreSQL.
But it is composed of only 8 tables, which is not enough to call the GEQO
algorithm.
I don't want to change any of the 22 queries provided by the TPC-H to call
the GEQO, and not lose the credibility of the TPC's tool.
