On Sat, Feb 21, 2009 at 10:41 PM, Tom Lane wrote:
> Scott Carey 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 a
Scott Carey 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 column to be possibly
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
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
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= 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.
regards
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 l
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= 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?
re
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 h
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:
http://www.postg
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
sathiya psql 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 on both machines and compare the output or
show the output here.
Andreas
--
Really, I'm not out to destroy Microsoft. Th
11 matches
Mail list logo
