Re: [PERFORM] Table Size

2007-01-16 Thread Guillaume Lelarge
Richard Huxton a écrit : > Gauri Kanekar wrote: >> Hi, >> >> Can anybody help me out to get following info of all the tables in a >> database. > > 1. Have you read up on the information schema and system catalogues? > http://www.postgresql.org/docs/8.2/static/catalogs.html > http://www.postgresql.

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

2007-01-16 Thread Scott Marlowe
On Tue, 2007-01-16 at 21:58 -0500, Jeremy Haile wrote: > Hey Chad, > > The table is heavily inserted and deleted from. Recently I had done a > very large delete. I still keep wondering if this table is bloated with dead tuples. Even if you vacuum often if there's a connection with an idle trans

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

2007-01-16 Thread Chad Wagner
On 1/16/07, Jeremy Haile <[EMAIL PROTECTED]> wrote: The table is heavily inserted and deleted from. Recently I had done a very large delete. That's what I suspected. Here is the results of the query you sent me: (sorry it's hard to read) "transaction_date";0;8;172593;-0.194848 Just curi

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

2007-01-16 Thread Jeremy Haile
Hey Chad, The table is heavily inserted and deleted from. Recently I had done a very large delete. Here is the results of the query you sent me: (sorry it's hard to read) "dcms_dim_id";0;4;755;-0.00676181 "transaction_fact_id";0;4;-1;-0.194694 "failed";0;4;2;0.964946 "van16";0;23;145866;0.00978

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

2007-01-16 Thread Chad Wagner
On 1/16/07, Jeremy Haile <[EMAIL PROTECTED]> wrote: Even if unrelated, do you think disk fragmentation would have negative effects? Is it worth trying to defragment the drive on a regular basis in Windows? Out of curiosity, is this table heavily updated or deleted from? Perhaps there is an

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

2007-01-16 Thread Jeremy Haile
Thanks Tom! Reducing random_page_cost to 2 did the trick for this query. It now favors the index scan. Even if this is a cached situation, I wouldn't expect a difference of 3 min vs 3 seconds. Even if unrelated, do you think disk fragmentation would have negative effects? Is it worth trying

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

2007-01-16 Thread Tom Lane
"Jeremy Haile" <[EMAIL PROTECTED]> writes: > Running PostgreSQL 8.2.1 on Win32. The query planner is choosing a seq > scan over index scan even though index scan is faster (as shown by > disabling seqscan). Table is recently analyzed and row count estimates > seem to be in the ballpark. Try red

[PERFORM] PG8.2.1 choosing slow seqscan over idx scan

2007-01-16 Thread Jeremy Haile
Running PostgreSQL 8.2.1 on Win32. The query planner is choosing a seq scan over index scan even though index scan is faster (as shown by disabling seqscan). Table is recently analyzed and row count estimates seem to be in the ballpark. Another tidbit - I haven't done a "vacuum full" ever, alth

Re: [PERFORM] Table Size

2007-01-16 Thread Richard Huxton
Gauri Kanekar wrote: Hi, Can anybody help me out to get following info of all the tables in a database. 1. Have you read up on the information schema and system catalogues? http://www.postgresql.org/docs/8.2/static/catalogs.html http://www.postgresql.org/docs/8.2/static/catalogs.html table_

Re: [PERFORM] Caching in PostgreSQL

2007-01-16 Thread Chris Browne
[EMAIL PROTECTED] writes: > Can anybody tell me how can I implement data Caching in the > shared memory using PostgreSQL. PostgreSQL already does that. Implementing this functionality is rather tricky: Between version 7.4 and now, it has seen *massive* change which has required a great deal

[PERFORM] Table Size

2007-01-16 Thread Gauri Kanekar
Hi, Can anybody help me out to get following info of all the tables in a database. table_len tuple_count tuple_len tuple_percent dead_tuple_count dead_tuple_len dead_tuple_percent free_space free_percent Thanks Gauri

Re: [PERFORM] Caching in PostgreSQL

2007-01-16 Thread David Levy
I am using memcached (http://www.danga.com/memcached/) to cache Postgres ADODB recordsets. It's very efficient but has to be implemented in your own application. On 1/16/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > We were looking on how to improve the per

Re: [PERFORM] Caching in PostgreSQL

2007-01-16 Thread Heikki Linnakangas
[EMAIL PROTECTED] wrote: We were looking on how to improve the performance of our application which is using PostgreSQL as backend.If postgreSQL is supporting data page caching in the shared memory then we wanted to design our application to read/write using the shared memory rather t

Re: [PERFORM] Caching in PostgreSQL

2007-01-16 Thread ramachandra.bhaskaram
Hi Heikki Linnakangas, Thanks for yoru kind response. We were looking on how to improve the performance of our application which is using PostgreSQL as backend.If postgreSQL is supporting data page caching in the shared memory then we wanted to design our application to read

Re: [PERFORM] Caching in PostgreSQL

2007-01-16 Thread Heikki Linnakangas
[EMAIL PROTECTED] wrote: Hi, Can anybody tell me how can I implement data Caching in the shared memory using PostgreSQL. PostgreSQL, like most other DBMS, caches data pages in shared memory. What exactly are you trying to accomplish? Are you having a performance problem? -- Hei

[PERFORM] Caching in PostgreSQL

2007-01-16 Thread ramachandra.bhaskaram
Hi, Can anybody tell me how can I implement data Caching in the shared memory using PostgreSQL. For one of the projects we are using Postgres version 8.0.3 and were planning to support table partitioning in order to improve the DB query/update performance but, it will be very m