[PERFORM] Bad optimization/planning on Postgres window-based queries (partition by(, group by?)) - 1000x speedup
see http://stackoverflow.com/questions/26237463/bad-optimization-planning-on-postgres-window-based-queries-partition-by-group for details -- View this message in context: http://postgresql.1045698.n5.nabble.com/Bad-optimization-planning-on-Postgres-window-based-queries-partition-by-group-by-1000x-speedup-tp5822190.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] Tables Without OIDS and its effect
Dear all , I have created my tables without OIDS now my doubts are : 1. Will this speed up the data insertion process 2. Though I have not written any code in my any of the pgsql functions which depend on OIDS 1. Will without OIDS the functions behave internally differently 2. Will my application break at any point 3. I decided to work with out OIDS because 1. It has a limit of -2147483648 to +2147483647 2 Due to this limitation I would not like to drop recreate my database because it is a bit difficult/dirty process All links and suggestion pertaining to OIDS are most welcome my mail box is at your disposal and dont hassitate to drop a two line comment. --- My Sys Config: RH9.0 PostgreSQL 7.3.4 GCC 3.2.2 PHP 4.3.4 -- Regards, V Kashyap ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] Tables Without OIDS and its effect
Hello Neil Conway, We are doing some test on our applications and will let know the community if without OIDS we could gain more speed . 2. Though I have not written any code in my any of the pgsql functions which depend on OIDS 1. Will without OIDS the functions behave internally differently 2. Will my application break at any point No. BTW, we intend to phase out the use of OIDs for user tables in the long term. There have been a few threads on -hackers that discuss the plans for doing this. This was a relief for us all , but an the same time we have found one incompatibility This incompatibility is with 1. StarOffice 7.0 2. OpenOffice 1.1 and the incompatibility is when I retrieve data into Star SpreadSheet or Open Office SpreadSheet I am greeted with an error field OID not found. Though these both are connecting to PostgreSQL 7.3.4 (Linux GCC 3.x) via psqlODBC 07.02.0003 On the Same time WinSQL connects as usual via psqlODBC 07.02.0003 and is working fine. Though this does not effect us a lot since we are using PHP to show and retrieve data We are posting this such that any one relying totally on OpenOffice for data retrieve and display better know this , Our Test config was: -- Client :- O.S Win XP (No service pack) OpenOffice 1.1 Windows version StarOffice 7.0 Eval Pack psqlODBC 07.02.0003 Server :- OS RH 9.0 kernel-2.4.20-24.9 PostgreSQL 7.3.4 Please if anyone has a different story while using WITHOUT OIDS please let us and every one know . Regards, V Kashyap
Re: [PERFORM] postgresql amd-64
Merlin, > Good, I'll give it a shot and see what I come up with...thx. > Do share your experience with us. -- With Best Regards, Vishal Kashyap. Did you know SaiPACS is one and only PACS Management tool. http://saihertz.com ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PERFORM] PostgreSQL and Kernel 2.6.x
Dear all, Have anyone compiled PostgreSQL with kernel 2.6.x if YES 1. Was their any performance gains Else 1. Is it possible 2. What problems would keeping us away from compiling on kernel 2.6 -- Best Regards, Vishal Kashyap Director / Lead Software Developer, Sai Hertz And Control Systems Pvt Ltd, http://saihertz.rediffblogs.com Jabber IM: vishalkashyap[ a t ]jabber.org ICQ : 264360076 Yahoo IM: mailforvishal[ a t ]yahoo.com --- You yourself, as much as anybody in the entire universe, deserve your love and affection. - Buddha --- pgsql=# select marital_status from vishals_life; marital_status -- Single not looking 1 Row(s) affected ---(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
