[ADMIN] test message
I seem to be having trouble getting message to the list. Can someone please reply if this message makes it. Thank you, Jodi Kanter ___Jodi L KanterBioInformatics Database AdministratorUniversity of Virginia(434) 924-2846[EMAIL PROTECTED]
[ADMIN] OOT : Two Lonely Days
I've been two days with no information,ask, question or etc from this milist. So, What's Up..?, Did the Admin kicked me out ??, What did I Do..??? Anybody Know what's exactly going on out there..?? Please..., GOD Bless You All. Yudha Setiawan.VoIP No. : 628899911223344
[ADMIN] Inquiry From Form [pgsql]
I have postgres running on Red Hat 7.3. I have my max connections set to 512..when i try to set this higher, the service will not start. is 512 the max? also, is there a command i can type in or a tool out there that will let me view active and inactive connections to the database? also, is there something out that that can \"kill\" the connections? Thank you.. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[ADMIN] Where are the current install instructions?
Will someone please provide or point out where current instructions are located for building and installing the database? The instructions at www.postgresql.org do not discuss the additional tar files (postgresql-opt-7.3.2.tar.gz, postgresql-test-7.3.2.tar.gz, postgresql-base-7.3.2.tar.gz, postgresql-docs-7.3.2.tar.gz) available for installation. The instructions only discuss the postgresql-7.3.2.tar.gz file. TIA. __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[ADMIN] displaying rules
Hello, is there a way to display created rules in psql environment? Regards Nat _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [ADMIN] displaying rules
> Hello, > > is there a way to display created rules in psql environment? > > Regards > Nat No \d option. But can get it from pg_rules system view. It contains the definition as well. regards, bhuvaneswaran ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[ADMIN] Performance question
When I execute a query on a new connection, the performance is many times slower than if the query is repeated. In other words, if I start psql, execute the query, then repeat it immediately, the second time it takes only about 20% as long to execute. Now here's the confusing part, if I exit psql then start it up again, the same thing will occur on the new connection as well, the first execution takes 5x as long again. I don't understand this, it would make sense to me that the second execution being faster is due to disk caching on the server, but then why is it slower again on every new connection? Disk caching should benefit all current and new connections until the cache is flushed, which on this server shouldn't happen for a long time, the load is light and it has lots of RAM. Is Postgres doing some kind of caching itself that lasts only for the life of one backend process? If so, is there any way to make this caching persistent across backends? Server particulars: Postgres 7.2.1, Mac OS X Server 10.1.5, dual 1GHz CPUs, 1.5GB memory Thanks! Bob Smith Hammett & Edison, Inc. [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Followup Re: [ADMIN] Performance question
OK, I seem to have fixed my own problem here again, sorry. I restarted the postmaster, now _all_ queries are about 10x faster, and the first execution on a new connection is no longer significantly slower than the second. The server (and the original postmaster) had been up for: 11:18AM up 162 days, 17:48, 3 users, load averages: 0.57, 0.51, 0.51 Maybe I should have a cron script restart postmaster every now and then, like once a week? Bob On Wednesday, Mar 5, 2003, at 10:11 US/Pacific, Bob Smith wrote: When I execute a query on a new connection, the performance is many times slower than if the query is repeated. In other words, if I start psql, execute the query, then repeat it immediately, the second time it takes only about 20% as long to execute. Now here's the confusing part, if I exit psql then start it up again, the same thing will occur on the new connection as well, the first execution takes 5x as long again. I don't understand this, it would make sense to me that the second execution being faster is due to disk caching on the server, but then why is it slower again on every new connection? Disk caching should benefit all current and new connections until the cache is flushed, which on this server shouldn't happen for a long time, the load is light and it has lots of RAM. Is Postgres doing some kind of caching itself that lasts only for the life of one backend process? If so, is there any way to make this caching persistent across backends? Server particulars: Postgres 7.2.1, Mac OS X Server 10.1.5, dual 1GHz CPUs, 1.5GB memory Thanks! Bob Smith Hammett & Edison, Inc. [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Followup Re: [ADMIN] Performance question
Is restarting postmaster on a regular basis necessary for performance? - Original Message - From: "Bob Smith" <[EMAIL PROTECTED]> To: "pgsql-admin" <[EMAIL PROTECTED]> Sent: Wednesday, March 05, 2003 2:20 PM Subject: Followup Re: [ADMIN] Performance question > > OK, I seem to have fixed my own problem here again, sorry. I restarted > the postmaster, now _all_ queries are about 10x faster, and the first > execution on a new connection is no longer significantly slower than > the second. The server (and the original postmaster) had been up for: > > 11:18AM up 162 days, 17:48, 3 users, load averages: 0.57, 0.51, 0.51 > > Maybe I should have a cron script restart postmaster every now and > then, like once a week? > > Bob > > On Wednesday, Mar 5, 2003, at 10:11 US/Pacific, Bob Smith wrote: > > > > > When I execute a query on a new connection, the performance is many > > times slower than if the query is repeated. In other words, if I > > start psql, execute the query, then repeat it immediately, the second > > time it takes only about 20% as long to execute. Now here's the > > confusing part, if I exit psql then start it up again, the same thing > > will occur on the new connection as well, the first execution takes 5x > > as long again. I don't understand this, it would make sense to me > > that the second execution being faster is due to disk caching on the > > server, but then why is it slower again on every new connection? Disk > > caching should benefit all current and new connections until the cache > > is flushed, which on this server shouldn't happen for a long time, the > > load is light and it has lots of RAM. Is Postgres doing some kind of > > caching itself that lasts only for the life of one backend process? > > If so, is there any way to make this caching persistent across > > backends? > > > > Server particulars: > > > > Postgres 7.2.1, Mac OS X Server 10.1.5, dual 1GHz CPUs, 1.5GB memory > > > > Thanks! > > > > Bob Smith > > Hammett & Edison, Inc. > > [EMAIL PROTECTED] > > > > > > ---(end of > > broadcast)--- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to [EMAIL PROTECTED] so that your > > message can get through to the mailing list cleanly > > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Can Any body discuss details of this Query Plan
Sreedhar, You need to run VACUUM on a regular basis in order to have up-to-date database statistics for the PostgreSQL planner. The EXPLAIN command just has an estimation of how many rows will get processed and what the best way should be to execute the query. Without good table statistics this estimation can be completely wrong. You say that your tempaccountid table has only 10 rows. However, EXPLAIN shows the default of 1000 rows. You say that the table tblPermissions has about 70,000 rows. But before indexing PostgreSQL does not know that and again assumed the default. By indexing the tblPermissions table you updated its statistics and therefore the second EXPLAIN looks different. Regards, Nikolaus Dilger "shreedhar" wrote: > > pmdummy=# explain SELECT projectid FROM tblPermissions > pmdummy-# INNER JOIN tempaccountid ON > tempaccountid.accid = tblPermissions. > countid > pmdummy-# WHERE tblPermissions.topid = 3915; > > 1. tempaccountid (accid integer) no indexe or no > primary key > Number of Records 10 > 2. tblPermissions (accountid integer, raccountid > integer, topid integer) > primary key(accountid, raccountid) >Number of Records appoximately 70, > > Before indexing on tblpermissions (topid) i got query > plan as > > > NOTICE: QUERY PLAN: > > Hash Join (cost=22.51..47.83 rows=25 width=12) > -> Seq Scan on tempaccountid (cost=0.00..20.00 > rows=1000 width=4) > -> Hash (cost=22.50..22.50 rows=5 width=8) > -> Seq Scan on tblpermissions > (cost=0.00..22.50 rows=5 width=8) > > EXPLAIN > > After indexing on tblpermissions (topid) i got query > plan as > > NOTICE: QUERY PLAN: > > Merge Join (cost=1345.76..1375.89 rows=2126 width=12) > -> Sort (cost=1275.93..1275.93 rows=425 width=8) > -> Index Scan using idx_tblpermissions_topid > on tblpermissions > (cost=0 > .00..1257.37 rows=425 width=8) > -> Sort (cost=69.83..69.83 rows=1000 width=4) > -> Seq Scan on tempaccountid > (cost=0.00..20.00 rows=1000 width=4) > > EXPLAIN > > But I could not under stand this statistics. Can any > body explain above. > > Thanks to all seniors and gurus, > > Sreedhar > > > "Faith, faith, faith in ourselves, faith, faith in God, > this is the secret > of greatness. > If you have faith in all the three hundred and thirty > millions of your > mythological gods, > and in all the gods which foreigners have now and again > introduced into your > midst, > and still have no faith in yourselves, there is no > salvation for you. " > (III. 190) > > > ---(end of > broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://mail.dilger.cc/jump/http://www.postgresql.org/users-lounge/docs/faq.html";>http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
