[PERFORM] Joining on text field VS int

Hi, I am going to test this out but would be good to know anyways. A large table is joined to a tiny table (8 rows) on a text field. Should I be joining on an int field eg: recid intead of name? Is the performance affected in either case? Thanks .

[PERFORM] Performance with partitions/inheritance and multiple tables

Hi, We currently have a large table (9 million rows) of which only the last couple of days worth of data is queried on a regular basis. To improve performance we are thinking of partitioning the table. One idea is: Current_data = last days worth archive_data today (goes back to 2005) The idea

[PERFORM] max fsm pages question

Hi, when i issued the vaccuum cmd, I recieved this message: echo VACUUM --full -d ARSys | psql -d dbname WARNING: relation public.tradetbl contains more than max_fsm_pages pages with useful free space HINT: Consider compacting this relation or increasing the configuration parameter

Re: [PERFORM] Replication Syatem

On Mon, Apr 28, 2008 at 9:38 AM, Gauri Kanekar [EMAIL PROTECTED] wrote: All, We have a table table1 which get insert and updates daily in high numbers, bcoz of which its size is increasing and we have to vacuum it every alternate day. Vacuuming table1 take almost 30min and during that time

[PERFORM] Database connections and stored procs (functions)

Hi, I am running postgres 8.2 on RH linux. My daemon downloads files and then inserts the data into preliminary tables, and finally calls a stored procedure which reads data from a view and inserts into the final table. I have a bit of a peculiar problem. (I understand this may not be the right

Re: [PERFORM] Shared Buffer setting in postgresql.conf

Thank you scott. We plan on upgrading to Postgres 8.2 very soon. Would it be safe to say I can make my SHARED BUFFER setting 200MB (I have 2GB memory ). The default is 24MB. Regds, Radhika On 10/10/07, Scott Marlowe [EMAIL PROTECTED] wrote: On 10/9/07, Radhika S [EMAIL PROTECTED] wrote: Hi

[PERFORM] Shared Buffer setting in postgresql.conf

Hi, Along with my previous message (slow postgres), I notice the shared buffer setting for our production database is set to 1000. How much higher can I go? I don't know how much my kernel can take? I am running postgres 7.4.6 on Redhat enterprise 3 server. Thanks, Radhika -- It is all a

[PERFORM] Postgres running Very slowly

Hi -, I have a very peculiar situation. I am running a postgres 7.4.6 database. It is running slow... . I vacuum --analyze daily. I just did again. I did a vacuum full last night. But to no avail. CPU usage and memory are normal, but the system is crawling. Here is the info from vacuum.

[PERFORM] Difference between Vacuum and Vacuum full

Hi, I have recently had to change our nightly jobs from running vacuum full, as it has caused problems for us. Upon doing more reading on this topic, I understand that vacuum full needs explicit locks on the entire db and explicit locking conflicts with all other locks. But this has bought me to

Re: [PERFORM] Difference between Vacuum and Vacuum full

Thank you much for such a precise explanation. That was very helpful. Regards, Radhika On 10/2/07, Scott Marlowe [EMAIL PROTECTED] wrote: On 10/2/07, Radhika S [EMAIL PROTECTED] wrote: Hi, I have recently had to change our nightly jobs from running vacuum full, as it has caused

[PERFORM] Postgres 7.4.2 hanging when vacuum full is run

Hi - This has been happening more recently. Our database hangs after a VACUUM and is unresponsive when we come in next morning. The vacuum job runs at 03:00 am daily. The command is : /usr/local/pgsql/bin/vacuumdb --full -d DbName Also, what exactly does this mean VACUUM waiting. Is there a

[PERFORM] Difference in query plan when using = or in where clause

Hi, I am curious as to why this occurs. Why does an = change the query plan so drastically? When my query is: Select count(*) from View_A WHERE tradedate = '20070801'; The query plan is as below: I see that the scan on the alloctbl is being indexed on k_alloctbl_blockid_status - Bitmap Index