Hi,
forgive me the poor English for the writing, for technique reading is a
little better..
Sees, below, that it seems to have one bug in set transform_null_equals
or, then, in <> NULL.
This fact occurs in Versions: 7.4.5 and 8.0.0-rc2.
-- Creation with transform_null_equals set to off
set
"Luiz Gonzaga da Mata" <[EMAIL PROTECTED]> writes:
> Sees, below, that it seems to have one bug in set transform_null_equals
> or, then, in <> NULL.
transform_null_equals only catches the exact syntax "something = NULL".
It does not touch "something <> NULL". The latter is always going to
yield N
I've simplified the test case to the following:
CREATE TABLE foo (
id integer NOT NULL,
value integer NOT NULL
);
INSERT INTO foo (id, value)
SELECT random() * 1000, random() * 1000
FROM generate_series(1, 10);
CREATE INDEX foo_id_idx ON foo (id);
CREATE INDEX foo_value_idx
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Limit (cost=0.00..25.79 rows=1 width=8) (actual time=631.964..631.964
> rows=0 loops=1)
>-> Index Scan using foo_value_idx on foo (cost=0.00..2552.75 rows=99
> width=8) (actual time=631.942..631.942 rows=0 loops=1)
> Filter: (id = -1)
>
On Sun, Jan 16, 2005 at 02:56:11PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
>
> > Maybe I don't understand something about what EXPLAIN is showing,
> > but why does Limit have an estimated cost of 0.00..25.79 when the
> > thing it's limiting has a cost of 0.00..2552.75?
>
> transform_null_equals only catches the exact syntax "something = NULL". It
> does not touch "something <> NULL". The latter is always going to yield
> NULL, by definition.
Yes, I saw this in parser_expr.c and the documentation.
1)In code "dtpagto IS NULL" is not the same thing that !(dtpagto I
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Would it be accurate to say that the planner makes the bet most
> likely to win without regard to how badly it might lose?
Yes, I think that's a fair summary.
> Is taking the downside into consideration a tough problem to solve, or
> is it simply not wor
Developers,
I'm finding an issue I thought was fixed with RC2, which is affecting my
ability to use arrays in RC5:
Summary: Fast repeated calls to INT[] = INT[] operator causes error
Severity: Query Failure
Version: 8.0.0rc5, previous builds of 8.0.0
Platform: Gentoo Linux
Description:
Th
Folks,
> I'm finding an issue I thought was fixed with RC2, which is affecting my
> ability to use arrays in RC5:
Oh, this may be a bug specifically in INTARRAY; that module is installed.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast
Josh Berkus writes:
> However, we're found that if you run thousands of empty array comparisons in
> a
> few seconds/minutes, eventually the empty array comparison breaks, and you
> get:
> ERROR: cache lookup failed for function 0
I tried
while true; do echo "select '{}'::INT[] = '{}'::INT[]
On Sun, Jan 16, 2005 at 04:08:35PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
>
> > Is taking the downside into consideration a tough problem to solve, or
> > is it simply not worthwhile in the large?
>
> I don't know how to solve it, and whether it would be worthwhile woul
11 matches
Mail list logo
