On Tue, 2004-06-08 at 08:36, Josuà Maldonado wrote:
> Hello Scott,
SNIP...
> > Your numbers show that you are tossing 659M and 314M against each other,
> > but I don't know if you're harvesting the whole set at once, or just a
> > couple row of each. Indexing help, or is this always gonna be a b
Hello Scott,
El 07/06/2004 4:47 PM, Scott Marlowe en su mensaje escribio:
OK, you have to ask yourself a question here. Do I have enough memory
to let both postgresql and the kernel to cache this data, or enough
memory for only one. Then, you pick one and try it out. But there's
some issues here
=?ISO-8859-1?Q?Josu=E9_Maldonado?= <[EMAIL PROTECTED]> writes:
> Recreated the index (drop then create) and did the vacuum full pkardex
> and the behavior seems to be the same:
Well, there was a pretty huge improvement in the pkardex scan time,
whether you noticed it or not: 39520.406 to 87.393 m
Josh,
El 07/06/2004 5:21 PM, Josh Berkus en su mensaje escribio:
Huh? It is not at all the same. Your index scan is down to 87ms from
27,000! And the total query is down to 16seconds from 47 seconds. Don't
you consider that an improvement?
Yes there was an improvement with respect the pre
Josue'
> dbmund=# explain analyze select * from vkardex where kprocode='1013';
> Nested Loop (cost=0.00..2248.19 rows=403 width=114) (actual
> time=846.318..16030.633 rows=3145 loops=1)
> -> Index Scan using pkd_pcode_idx on pkardex (cost=0.00..806.27
> rows=403 width=72) (actual time=0
Hi Josh and thanks for your response,
El 07/06/2004 4:31 PM, Josh Berkus en su mensaje escribio:
Josue'
-> Index Scan using pkd_pcode_idx on pkardex (cost=0.00..11292.52
rows=5831 width=72) (actual time=18.152..39520.406 rows=5049 loops=1)
Looks to me like there's a problem with index bloat
On Mon, 2004-06-07 at 16:19, Josuà Maldonado wrote:
> Hello list,
>
> Server is dual Xeon 2.4, 2GBRAM, Postgresql is running on partition:
> /dev/sda9 29G 8.9G 20G 31% /home2
> /dev/sda9 on /home2 type jfs (rw)
>
> Version()
> PostgreSQL 7.4 on i686-pc-linux-gnu, compiled by GCC
Josue'
> -> Index Scan using pkd_pcode_idx on pkardex (cost=0.00..11292.52
> rows=5831 width=72) (actual time=18.152..39520.406 rows=5049 loops=1)
Looks to me like there's a problem with index bloat on pkd_pcode_idx. Try
REINDEXing it, and if that doesn't help, VACUUM FULL on pkardex.
Hello list,
Server is dual Xeon 2.4, 2GBRAM, Postgresql is running on partition:
/dev/sda9 29G 8.9G 20G 31% /home2
/dev/sda9 on /home2 type jfs (rw)
Version()
PostgreSQL 7.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2
20020903 (Red Hat Linux 8.0 3.2-7)
I have a view to jo
