[postgis-users] Query parallelization in via pgpool
Hello everyone I am new to pgpool.I have installed Pgpool-II-3.0.4 and pgpoolAdmin-3.0 . I want to use feature of pgpool query distribution and rejoining .I know about the things we need to change in pgpool.conf for query parallelization and we can set it by pgpoolAdmin too. I want to fire my query from java interface so i want to make connection of pgpool and postgresql whether i need to join java to both postgresql and pgpool or i need to join java to postgresql and pgpool to postgresql...m confused. Can some information about Systemdb and dblink that is used for query distribution and rejoining is provided by any1... plz help me who have done some experiment like this one ??? I am waiting for help and a vry thankyou in advance for any help.. -- Regards Monika Yadav ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] compile on solaris 11 sparc
On 02/09/11 18:02, Doug McComber wrote: I've got this in my profile: # 64 bit compiling CC=gcc CXX=g++ CPP=gcc CFLAGS=-m64 CPPFLAGS=-m64 CXXFLAGS=-m64 # 3rd party libray LDFLAGS=-L/usr/local/lib and ran source ~/.profile Despite that I found I had to add some of that to the configure command (shouldn't have to log out after sourcing profile right?) like so: ./configure CC=gcc CFLAGS=-m64 CPPFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-L/usr/local/lib --with-geosconfig=/usr/local/bin/geos-config This completes without error. The only warnings I saw were about dblatex and CUnit. The final output of configure being: PostGIS is now configured for sparc-sun-solaris2.11 -- Compiler Info - C compiler: gcc -m64 C++ compiler: g++ -m64 -- Dependencies -- GEOS config: /usr/local/bin/geos-config GEOS version: 3.3.0 PostgreSQL config: /usr/postgres/9.0-pgdg/bin/64/pg_config PostgreSQL version: PostgreSQL 9.0.4 PROJ4 version: 47 Libxml2 config: /usr/bin/xml2-config Libxml2 version: 2.7.6 PostGIS debug level: 0 Documentation Generation xsltproc: /usr/bin/xsltproc xsl style sheets: dblatex: convert: /usr/bin/convert Make starts out well but dies with an error complaining about not finding SunStudio! gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o g_util.o g_util.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o lwgeodetic.o lwgeodetic.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o lwtree.o lwtree.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -ffloat-store -c -o lwspheroid.o lwspheroid.c ar rs liblwgeom.a measures.o box2d.o ptarray.o lwgeom_api.o lwgeom.o lwpoint.o lwline.o lwpoly.o lwmpoint.o lwmline.o lwmpoly.o lwcollection.o lwcircstring.o lwcompound.o lwcurvepoly.o lwmcurve.o lwmsurface.o lwutil.o lwalgorithm.o lwgunparse.o lwgparse.o lwsegmentize.o wktparse.tab.o lex.yy.o vsprintf.o g_box.o g_coord.o g_geometry.o g_ptarray.o g_serialized.o g_util.o lwgeodetic.o lwtree.o lwspheroid.o ar: creating liblwgeom.a make[1]: Leaving directory `/home/doug/sources/postgis-1.5.3/liblwgeom' make -C postgis make[1]: Entering directory `/home/doug/sources/postgis-1.5.3/postgis' /opt/studio11/SUNWspro/bin/cc -Xa -E -traditional-cpp postgis.sql.in.c | grep -v '^#' postgis.sql.in /bin/sh: line 1: /opt/studio11/SUNWspro/bin/cc: not found make[1]: *** [postgis.sql.in] Error 1 make[1]: *** Deleting file `postgis.sql.in' make[1]: Leaving directory `/home/doug/sources/postgis-1.5.3/postgis' make: *** [postgis] Error 2 This is a Solaris 11 box I should mention and gcc was installed from the Oracle Solaris 11 repository as opposed to a 3rd-party package or from source. I don't have Sun Studio installed (never did) and other programs compiled without problem (Proj 4 and GEOS). This error /opt/studio11/SUNWspro/bin/cc: not found appears to be PostGIS specific (according to Google anyway). Suggestions? Right, so currently the .sql files are generated using the C pre-processor and so uses the CPP variable in addition to the ones defined above. I'm not sure what the correct command line should be to invoke the pre-processor in Sun's compiler is though. I think we need to start thinking about ripping the CPP code out and finding something more suitable instead, particularly when thinking about building other platforms such as Win32/64. I'm not exactly sure what the replacement should be though :/ ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] compile on solaris 11 sparc
Please pardon my ignorance of all things windows but is the cpp not one of those universal components of the c programming environment? (apologies in advance I know.this is not a postgis question) On Sep 5, 2011 4:51 AM, Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk wrote: On 02/09/11 18:02, Doug McComber wrote: I've got this in my profile: # 64 bit compiling CC=gcc CXX=g++ CPP=gcc CFLAGS=-m64 CPPFLAGS=-m64 CXXFLAGS=-m64 # 3rd party libray LDFLAGS=-L/usr/local/lib and ran source ~/.profile Despite that I found I had to add some of that to the configure command (shouldn't have to log out after sourcing profile right?) like so: ./configure CC=gcc CFLAGS=-m64 CPPFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-L/usr/local/lib --with-geosconfig=/usr/local/bin/geos-config This completes without error. The only warnings I saw were about dblatex and CUnit. The final output of configure being: PostGIS is now configured for sparc-sun-solaris2.11 -- Compiler Info - C compiler: gcc -m64 C++ compiler: g++ -m64 -- Dependencies -- GEOS config: /usr/local/bin/geos-config GEOS version: 3.3.0 PostgreSQL config: /usr/postgres/9.0-pgdg/bin/64/pg_config PostgreSQL version: PostgreSQL 9.0.4 PROJ4 version: 47 Libxml2 config: /usr/bin/xml2-config Libxml2 version: 2.7.6 PostGIS debug level: 0 Documentation Generation xsltproc: /usr/bin/xsltproc xsl style sheets: dblatex: convert: /usr/bin/convert Make starts out well but dies with an error complaining about not finding SunStudio! gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o g_util.o g_util.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o lwgeodetic.o lwgeodetic.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o lwtree.o lwtree.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -ffloat-store -c -o lwspheroid.o lwspheroid.c ar rs liblwgeom.a measures.o box2d.o ptarray.o lwgeom_api.o lwgeom.o lwpoint.o lwline.o lwpoly.o lwmpoint.o lwmline.o lwmpoly.o lwcollection.o lwcircstring.o lwcompound.o lwcurvepoly.o lwmcurve.o lwmsurface.o lwutil.o lwalgorithm.o lwgunparse.o lwgparse.o lwsegmentize.o wktparse.tab.o lex.yy.o vsprintf.o g_box.o g_coord.o g_geometry.o g_ptarray.o g_serialized.o g_util.o lwgeodetic.o lwtree.o lwspheroid.o ar: creating liblwgeom.a make[1]: Leaving directory `/home/doug/sources/postgis-1.5.3/liblwgeom' make -C postgis make[1]: Entering directory `/home/doug/sources/postgis-1.5.3/postgis' /opt/studio11/SUNWspro/bin/cc -Xa -E -traditional-cpp postgis.sql.in.c | grep -v '^#' postgis.sql.in /bin/sh: line 1: /opt/studio11/SUNWspro/bin/cc: not found make[1]: *** [postgis.sql.in] Error 1 make[1]: *** Deleting file `postgis.sql.in' make[1]: Leaving directory `/home/doug/sources/postgis-1.5.3/postgis' make: *** [postgis] Error 2 This is a Solaris 11 box I should mention and gcc was installed from the Oracle Solaris 11 repository as opposed to a 3rd-party package or from source. I don't have Sun Studio installed (never did) and other programs compiled without problem (Proj 4 and GEOS). This error /opt/studio11/SUNWspro/bin/cc: not found appears to be PostGIS specific (according to Google anyway). Suggestions? Right, so currently the .sql files are generated using the C pre-processor and so uses the CPP variable in addition to the ones defined above. I'm not sure what the correct command line should be to invoke the pre-processor in Sun's compiler is though. I think we need to start thinking about ripping the CPP code out and finding something more suitable instead, particularly when thinking about building other platforms such as Win32/64. I'm not exactly sure what the replacement should be though :/ ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] compile on solaris 11 sparc
Yeah, I was going to ask a similar question: we want a tool that does everything cpp does (replacements, inclusions, conditions), but isn't cpp? P. On Mon, Sep 5, 2011 at 8:06 AM, Chris Hermansen chris.herman...@tecogroup.ca wrote: Please pardon my ignorance of all things windows but is the cpp not one of those universal components of the c programming environment? (apologies in advance I know.this is not a postgis question) On Sep 5, 2011 4:51 AM, Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk wrote: On 02/09/11 18:02, Doug McComber wrote: I've got this in my profile: # 64 bit compiling CC=gcc CXX=g++ CPP=gcc CFLAGS=-m64 CPPFLAGS=-m64 CXXFLAGS=-m64 # 3rd party libray LDFLAGS=-L/usr/local/lib and ran source ~/.profile Despite that I found I had to add some of that to the configure command (shouldn't have to log out after sourcing profile right?) like so: ./configure CC=gcc CFLAGS=-m64 CPPFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-L/usr/local/lib --with-geosconfig=/usr/local/bin/geos-config This completes without error. The only warnings I saw were about dblatex and CUnit. The final output of configure being: PostGIS is now configured for sparc-sun-solaris2.11 -- Compiler Info - C compiler: gcc -m64 C++ compiler: g++ -m64 -- Dependencies -- GEOS config: /usr/local/bin/geos-config GEOS version: 3.3.0 PostgreSQL config: /usr/postgres/9.0-pgdg/bin/64/pg_config PostgreSQL version: PostgreSQL 9.0.4 PROJ4 version: 47 Libxml2 config: /usr/bin/xml2-config Libxml2 version: 2.7.6 PostGIS debug level: 0 Documentation Generation xsltproc: /usr/bin/xsltproc xsl style sheets: dblatex: convert: /usr/bin/convert Make starts out well but dies with an error complaining about not finding SunStudio! gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o g_util.o g_util.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o lwgeodetic.o lwgeodetic.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -c -o lwtree.o lwtree.c gcc -m64 -fPIC -DPIC -Wall -Wmissing-prototypes -ffloat-store -c -o lwspheroid.o lwspheroid.c ar rs liblwgeom.a measures.o box2d.o ptarray.o lwgeom_api.o lwgeom.o lwpoint.o lwline.o lwpoly.o lwmpoint.o lwmline.o lwmpoly.o lwcollection.o lwcircstring.o lwcompound.o lwcurvepoly.o lwmcurve.o lwmsurface.o lwutil.o lwalgorithm.o lwgunparse.o lwgparse.o lwsegmentize.o wktparse.tab.o lex.yy.o vsprintf.o g_box.o g_coord.o g_geometry.o g_ptarray.o g_serialized.o g_util.o lwgeodetic.o lwtree.o lwspheroid.o ar: creating liblwgeom.a make[1]: Leaving directory `/home/doug/sources/postgis-1.5.3/liblwgeom' make -C postgis make[1]: Entering directory `/home/doug/sources/postgis-1.5.3/postgis' /opt/studio11/SUNWspro/bin/cc -Xa -E -traditional-cpp postgis.sql.in.c | grep -v '^#' postgis.sql.in /bin/sh: line 1: /opt/studio11/SUNWspro/bin/cc: not found make[1]: *** [postgis.sql.in] Error 1 make[1]: *** Deleting file `postgis.sql.in' make[1]: Leaving directory `/home/doug/sources/postgis-1.5.3/postgis' make: *** [postgis] Error 2 This is a Solaris 11 box I should mention and gcc was installed from the Oracle Solaris 11 repository as opposed to a 3rd-party package or from source. I don't have Sun Studio installed (never did) and other programs compiled without problem (Proj 4 and GEOS). This error /opt/studio11/SUNWspro/bin/cc: not found appears to be PostGIS specific (according to Google anyway). Suggestions? Right, so currently the .sql files are generated using the C pre-processor and so uses the CPP variable in addition to the ones defined above. I'm not sure what the correct command line should be to invoke the pre-processor in Sun's compiler is though. I think we need to start thinking about ripping the CPP code out and finding something more suitable instead, particularly when thinking about building other platforms such as Win32/64. I'm not exactly sure what the replacement should be though :/ ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] OT: Question on performance in plpgsql function
Hi all, This may be a little off topic, but there are a lot of smart minds here that might know. I have a plpgsql function the does some work to compute all the intersections with street names in a road network. It creates a vertex table like in pgrouting and an intersection table. Then populates the tables from a streets network and finally updates the intersection table based on the number of connected segments that have names. The performance issue I'm having is that if I include the final update in the procedure is takes forever (well longer than 12 hours when I aborted it) and postgres runs at 100 CPU for all that time. But if I comment out the update and run the procedure it takes say 1 hour to run, and then I then run the update from the command line it takes say another hour to run that, so a total of 2 hours. plpgsql function run in a single transaction and breaking it into two steps does it in two transaction, so I figure that has something to do with it. An you can not COMMIT in a plpgsql function. Any thoughts on how to fix this? Can a SQL procedure do a COMMIT? If so I might be able to reorg the process into two some plpgsql procedures that get called from a SQL procedure. Thoughts? -Steve ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
