For a certain record in our database I'm getting cache lookup failures
(ERROR: cache lookup failed for type 70385664). And only for one of
the 2 array columns in that record.
The table definition is:
\d inhoudingen
Table "public.inhoudingen"
Column|
8560e48) + 1a9
0850 ()
Not sure if that's of any help though... We are running postgresql 8.2.3 on
solaris 10.
Regards,
Wessel van Norel
On Tue, Jun 23, 2009 at 12:37 PM, DelGurth wrote:
> For a certain record in our database I'm getting cache lookup failures
> (
On Thu, Oct 16, 2008 at 4:40 PM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * Tomasz Ostrowski ([EMAIL PROTECTED]) wrote:
> I don't see 'limit 1' anywhere in that patch.. And you don't want to
> use 'limit 1' *and* count(*), that doesn't do what you're expecting
> (since count(*) is an aggregate a
On 1/31/07, Geoffrey <[EMAIL PROTECTED]> wrote:
We are trying to track down an issue with our PostgreSQL application.
We are running PostgreSQL 7.4.13 on Red Hat Enterprise ES 3.
We have a situation where the postgres backend process drops core and
dies. We've tracked this to an unusual situati
Slightly OT. That documentation page of postgresql contains an invalid
example. Not sure if I should report it in here, but well, there you
go.
CREATE SEQUENCE serial START 101;
SELECT nextval('serial');
nextval
-
114
So you start at 101 and get 114, how nice ;-)
Regards,
Wessel van
Alban Hertroys writes:> Is there a trick to make this work a bit faster?
Have you really shown us the right queries for those explain results?I don't see where the second plan is testing "dir <> 1" at all.It looks like the first one is faster because it's using a partial
index that has predicate d
BTW, what PG version is this exactly?Our PG version is the version downloadable from
http://www.sunfreeware.com/programlistsparc10.html#postgresql , so 8.0.1 for solaris sparc.Sorry I was wrong on this point, it's 8.1.4-bash-3.00$ pg_config --versionPostgreSQL
8.1.4And it's the version from b
On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Hmph ... it certainly appears to be choosing the wrong index in thesecond case. I wonder why --- can you show the relpages and reltuplesstats from pg_class for these indexes?I'm personally not aware how to do that, perhaps Alban will (tell me how to)
