"Chris Faulkner" <[EMAIL PROTECTED]> writes:
> I am seeing this message in my logs.
> "bt_fixroot: not valid old root page"
That's not good. I'd suggest reindexing that index.
regards, tom lane
---(end of broadcast)---
TIP
Chris, People:
(Dropped SQL list because we're cross-posting unnecessarily)
> I am not sure I agree with you. I have done similar things with Oracle and
> found that the second query will execute much more quickly than the first.
> It could be made to work in at least two scenarios
Actually, Po
On Saturday 11 October 2003 12:12, Chris Faulkner wrote:
> Hello
>
> Thanks for the reply.
>
> > The short answer is that PG doesn't cache query results. The only
> > way it could
> > do so safely is to lock all tables you access to make sure that no other
> > process changes them. That would effec
Nested Loop (cost=0.00..147.11 rows=1 width=148) (actual
time=84.00..12323.00 rows=67 loops=1)
The planner estimate doesn't seem to match reality in that particular
step. Are you sure you've run:
ANALYZE oscar_node;
ANALYZE oscar_point;
And you could even run VACUUM FULL on them just to make
Nested Loop (cost=0.00..147.11 rows=1 width=148) (actual
time=84.00..12323.00 rows=67 loops=1)
The planner estimate doesn't seem to match reality in that particular
step. Are you sure you've run:
ANALYZE oscar_node;
ANALYZE oscar_point;
And you could even run VACUUM FULL on them just to make
Hello
Thanks for the reply.
> The short answer is that PG doesn't cache query results. The only
> way it could
> do so safely is to lock all tables you access to make sure that no other
> process changes them. That would effectively turn PG into a
> single-user DB in
> short notice.
I am not sur
On Saturday 11 October 2003 10:43, Chris Faulkner wrote:
> Hello all
>
> I have two very similar queries which I need to execute. They both have
> exactly the same from / where conditions. When I execute the first, it
> takes about 16 seconds. The second is executed almost immediately after, it
> t
