Re: [PERFORM] High CPU usage after partitioning

On Tue, Jan 22, 2013 at 3:46 PM, Andrew Dunstan wrote: > The query is pretty simple and standard, the behaviour (and the plan) is > totally different when it comes to a partitioned table. > >> >> Partioned table query => explain analyze SELECT "sb_logs".* FROM >> "sb_logs" WHERE (device_id = 90

Re: [PERFORM] High CPU usage after partitioning

On Tue, Jan 22, 2013 at 3:04 PM, Merlin Moncure wrote: > let's see the query -- it's probably written in such a way so as to > not be able to be optimized through CE. > > The query is pretty simple and standard, the behaviour (and the plan) is totally different when it comes to a partitioned tabl

Re: [PERFORM] High CPU usage after partitioning

On Tue, Jan 22, 2013 at 1:41 AM, Andrew Dunstan wrote: > > On 01/21/2013 10:05 AM, rudi wrote: > >> Hello, >> >> I'm running postgresl 9.0. After partitioning a big table, CPU usage >> raised from average 5-10% to average 70-80%. >> >> - the ta

[PERFORM] High CPU usage after partitioning

Hello, I'm running postgresl 9.0. After partitioning a big table, CPU usage raised from average 5-10% to average 70-80%. - the table contains about 20.000.000 rows - partitions are selected using a trigger, based on an indexed field, a date (IF date_taken >= x AND date_taken < y) - I created 5 pa

Re: [PERFORM] VACUUM killing my CPU

nderstand what Alan has pointed out. Your CPU processes are waiting on the HDD ... HTH -- Regards, Rudi ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] optimized counting of web statistics

you mean a you are using 'plpython' inside PostgreSQL or using Python to execut select statements and crunch the data 'outside' PostgreSQL? Your reply is very interesting. Thanks. Regards, Rudi. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] slow queries, possibly disk io

of cascade all over that place. For example Apache connections went right up and hit their max. I am not sure how accurate the % is but it has work pretty well for me. Perhaps use this command in another window with you run your SQL and see what it shows. HTH. Kind reg

[PERFORM] NFS RAID 0/5

machine with RAID 0 but not ready for a day or so. I will soon need to move the databases onto the NFS partition and am concerned it will increase my problem. Any advise much appreciated. Thank you. Regards, Rudi ---(end of broadcast)--- TIP 2

Re: [PERFORM] [GENERAL] How to know which queries are to be optimised?

ook at the "Practical Query Analyser" - haven't used it myself yet, but it seems a sensible idea. http://pqa.projects.postgresql.org/ Cheers, Rudi. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

[PERFORM] Buld Insert and Index use.

AND gp.plan_no = '$plan_no' AND gp.street_no = '$street_no' AND gp.street_name = '$street_name' AND gp.suburb_postcode = $suburb_postcode "; Do you think an Index or Seq. scan should be used? Thanks. Regards, Rudi. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Bulk Insert and Index use

Hi, In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Rudi Starcevic) transmitted: A minute for your thoughts and/or suggestions would be great. Heh heh Could you give a more concrete example? E.g. - the DDL for the table(s), most particularly. Thanks, I didn'

Re: [PERFORM] Bulk Insert and Index use

the final table like: insert into original (x,x,x) (select temp.1, temp.2, etc from temp left join original on temp.street=original.street where original.street is null) Good Luck Jim Rudi Starcevic wrote: Hi, I have a question on bulk checking, inserting into a table and how best to use an index

[PERFORM] Bulk Insert and Index use

s are to use either and index or sequential scan and see which is faster. A minute for your thoughts and/or suggestions would be great. Thanks. Regards, Rudi. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] SELECT's take a long time compared to other DBMS

ead - Good luck. Regards Rudi. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] SELECT's take a long time compared to other DBMS

Hi, And yes I did a vacuum. Did you 'Analyze' too ? Cheers Rudi. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] Indexing question

e one 'current' table and one 'historical' table The 'historical' table will contain every transaction recorded from the current table. Regards Rudi. ---(end of broadcast)--- TIP 2: you can get off all lists at once wit

Re: [PERFORM] How to configure the postgresql.conf files

Chris, Oops - it's changed ! Here's the link's you need: http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html Cheers Rudi. Chris_Wu wrote: >Hello all! > I'm a new to Postgre

Re: [PERFORM] How to configure the postgresql.conf files

Hi Chris, I suggest you read this tech. document: http://www.varlena.com/GeneralBits/ I think you'll it's the best place to start. Cheers Rudi. Chris_Wu wrote: >Hello all! > I'm a new to Postgresql , I have never used it before. > I am having an