Tom Lane wrote:
> It appears that join_clause_is_redundant() is rejecting the clause as
> redundant. I suppose some part of that machinery gets confused by the
> fact that the RHS of the clause references both relations. The
> EquivalenceClass rewrite cleaned this whole area up greatly, so no
> s
I kept a copy of the data files in case it is needed, but I have to
check first, if I am allowed to give away that information. Some of the
data is confidential. If you just need the files containing the dammaged
table, this won't be a big problem, because it does not contain any
confidential infor
"Marc Schablewski" <[EMAIL PROTECTED]> writes:
> I kept a copy of the data files in case it is needed, but I have to
> check first, if I am allowed to give away that information. Some of the
> data is confidential. If you just need the files containing the dammaged
> table, this won't be a big pro
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I don't understand that code very well. Why does it think that the right
> pathkeys of "test1.id = test2.id" and "test1.id = test1.id+test2.id" are
> equal?
They *will* be equal ... after the join (if correctly implemented :-().
The problem is the c
The following bug has been logged online:
Bug reference: 3502
Logged by: Marc Frappier
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: windows XP
Description:pg_ctl register translates \ to /
Details:
I'm creating a windows service usin
"Sergey Burladyan" <[EMAIL PROTECTED]> writes:
> Description:may be Query Error: subplan does not executed
I've applied a patch for this; it'll be in the next set of releases.
regards, tom lane
---(end of broadcast)-
From this snipped you can see that the Bitmap Heap scan returns 123
rows, but the BitmapAnd under it returns 0. I would find it useful to
determine how many rows were thrown out by the recheck.
-> Bitmap Heap Scan on d (cost=4959.18..16848.23
rows=754 width=10) (actual
Flavio Botelho wrote:
I know the application should not be doing this. But i wonder if lots of the
complaints about postgres performance couldnt be related to problems like
this. I suggest that you change the behaviour of something like that from
silently accepting the string value to throwing a
David Fetter and I were just looking at something on IRC...
decibel=# select most_common_vals[1] from pg_stats where tablename='pg_depend'
and attname='classid';
ERROR: cannot subscript type anyarray because it is not an array
decibel=# select most_common_freqs[1] from pg_stats where tablename='
Decibel! <[EMAIL PROTECTED]> writes:
> ISTM you'd want to be able to reference an individual element of an
> ANYARRAY...
And what type would the result have?
pg_statistic is definitely pushing the boundaries of the type system
by having an anyarray column. We don't allow that in normal user
tabl
Decibel! wrote:
> David Fetter and I were just looking at something on IRC...
>
> decibel=# select most_common_vals[1] from pg_stats where
> tablename='pg_depend' and attname='classid';
> ERROR: cannot subscript type anyarray because it is not an array
> decibel=# select most_common_freqs[1] fro
11 matches
Mail list logo
