Hi,
I have a pretty trivial query that seems to take an excessive amount of time
to run, and while doing so is only consuming 5-10% of CPU. It looks like the
rest of the time is spent doing disk access (the hd is certainly grinding
away a lot).
I'm not sure whether this is able to be improved, an
>I have somewhere around 3M rows in the image table, and 37K rows in the
>ancestry table. The following is representative of some of the common
>queries I issue:
>
>select * from image natural join ancestry where ancestorid=100 and
>(state & 7::bigint) = 0::bigint;
>
"Robert Wille" <[EMAIL PROTECTED]> writes:
> select * from image natural join ancestry where ancestorid=100 and
> (state & 7::bigint) = 0::bigint;
The planner is not going to have any statistics that allow it to predict
the number of rows satisfying that &-condition, and so it's unsurprising
i
I have a number of very common queries that the
optimizer plans a very inefficient plan. I vacuum hourly. I'm wondering what I
can do to make the queries faster.
Here are the relevant tables:
create table image( imageid
integer not null, /* The image's ID */
containerid intege
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 27 June 2003 12:44, scott.marlowe wrote:
> This is actually normal. Look at the amount cached: 6257620K. That's
> 6.2Gig of cache. Linux is using only 6517776k - 6257620k of memory, the
> rest is just acting as kernel cache. If anything t
