sathiya psql sathiya.p...@gmail.com schrieb:
can some body give me ideas on what to do for confirming what is the issue for
consuming much time for the query execution ?
Run
EXPLAIN ANALYSE your query on both machines and compare the output or
show the output here.
Andreas
--
Really, I'm
Hi all,
As the author of BenchmarkSQL and the founder of EnterpriseDB I
can assure you that BenchmarkSQL was NOT written specifically for
PostgreSQL.It is intended to be a completely database agnostic
tpc-c like java based benchmark.
However; as Jonah correctly points out in painstaking
after your recent commit Tom, the cost is sky-high, and also it takes
ages again with subselect version. In case of two table join. I have
to try the three way one.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
On Feb 16, 2009, at 9:07 AM, Craig Ringer wrote:
CREATE INDEX uidx_product_partno_producer_id
ON product
USING btree
(partno, producer_id);
CREATE INDEX idx_product_partno
ON product
USING btree
(partno);
Can I safely delete the second one?
You can safely delete BOTH in that it won't
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes:
after your recent commit Tom, the cost is sky-high, and also it takes
ages again with subselect version. In case of two table join. I have
to try the three way one.
Which commit, and what example are you talking about?
the foo bar example above, with notion that all columns are NOT NULL
behaves much different now. I noticed, that some of the 'anti join'
stuff has changed in cvs recently, but I don't know if that's to
blame.
Basically, what I can see, is that the subselect case is no longer of
lower cost, to the
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes:
the foo bar example above, with notion that all columns are NOT NULL
behaves much different now.
AFAIK the treatment of NOT IN subselects hasn't changed a bit since 8.3.
So I still find your complaint uninformative.
Are there any optimizations planned for the case where columns are defined as
NOT NULL? Or other special path filtering for cases where the planner can know
that the set of values in the subselect won't contain NULLs (such as in
(select a from b where (a 0 and a 1).
It turns out to be
On Fri, Feb 20, 2009 at 8:40 PM, Denis Lussier
denis.luss...@enterprisedb.com wrote:
Hi all,
As the author of BenchmarkSQL and the founder of EnterpriseDB I
can assure you that BenchmarkSQL was NOT written specifically for
PostgreSQL.It is intended to be a completely database
Scott Carey sc...@richrelevance.com writes:
Are there any optimizations planned for the case where columns are
defined as NOT NULL?
We might get around to recognizing that case as an antijoin sometime.
It's nontrivial though, because you have to check for an intermediate
outer join causing the
On Sat, Feb 21, 2009 at 10:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Scott Carey sc...@richrelevance.com writes:
Are there any optimizations planned for the case where columns are
defined as NOT NULL?
We might get around to recognizing that case as an antijoin sometime.
It's nontrivial
11 matches
Mail list logo
