[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 b

[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 "max_

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 th

[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 v

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 PR

[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 matte

[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. CPU

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 fro

[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

[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 rea

[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