Re: [PERFORM] count * performance issue

On Thu, Mar 6, 2008 at 5:31 PM, sathiya psql <[EMAIL PROTECTED]> wrote: > will you please tell, what is autovacuuming... and wat it ll do... is > there any good article in this > > > Read this --> http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#AU

Re: [PERFORM] count * performance issue

as well? If not then hmm turn it on and doing manual analyze then shouldnt I guess take much time! But yes, I will say if its possible go with the trigger option as that might be more helpful and a very fast way to do that. -- Shoaib Mir Fujitsu Australia Software Technology [EMAIL PROTECTED]

Re: [PERFORM] count * performance issue

of rows in a table and I guess might be much faster then doing a count(*) but yes if trigger can be an option that can be the easiest way to do it and fastest too. -- Shoaib Mir Fujitsu Australia Software Technology [EMAIL PROTECTED]

Re: [PERFORM] pg_stats how-to?

Can you be a little more specific? What exactly are you trying to achieve with pg_stats? You can always get help for documentation at --> http://www.postgresql.org/docs/8.2/static/view-pg-stats.html -- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 5/13/07, Yudhvir Singh Sidhu <

Re: [PERFORM] Vacuum full is slow

environment. I will recommend setting it to 0 first and then you can start moving it high as per your needs... -- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 3/19/07, Ruben Rubio <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > You don't have vacuum_c

Re: [PERFORM] Benchmarking PGSQL?

Have you tried pgbench yet? -- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 2/14/07, Krishna Kumar <[EMAIL PROTECTED]> wrote: Hello All, I'm a performance engineer, quite interested in getting deep into the PGSQL performance enhancement effort. In that regard, I have th

Re: [PERFORM] slow result

You can also try this one: ANALYZE tablename; select reltuples from pg_class where relname = 'tablename'; Will also give almost the same results I guess... ----- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/23/07, Bruno Wolff III <[EMAIL PROTECTED]> wrote:

Re: [PERFORM] Vacuum v/s Autovacuum

You will need to properly tune the thresholds for VACUUM and ANALYZE in case of autovacuuming process, so that you do not need to increase the max_fsm_pages oftenly... - Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/18/07, Bill Moran <[EMAIL PROTECTED]> wrote: In respo

Re: [PERFORM] Monitoring Transaction Log size

Suggested in case he wants to do a log switch after certain amount of time... --- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/18/07, Simon Riggs <[EMAIL PROTECTED]> wrote: On Wed, 2007-01-17 at 23:03 +0500, Shoaib Mir wrote: > archive_timeout (came in ver 8.2) might

Re: [PERFORM] Monitoring Transaction Log size

archive_timeout (came in ver 8.2) might help you with customizing the size for log files. - Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/17/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Ziegelwanger, Silvio wrote: > Hi, > > > > how can I mo

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

A good idea here will be to first do a VACUUM FULL and then keep the Autovacuum settings you want. - Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/17/07, Jeremy Haile <[EMAIL PROTECTED]> wrote: > I still keep wondering if this table is bloated with dead tupl

Re: [PERFORM] Large table performance

help solving the problem... - Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/14/07, Dave Dutcher <[EMAIL PROTECTED]> wrote: Have you run vacuum and analyze on the table? What version of Postgres are you running? What OS are you using? This looks like a straight forward

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

ry if they are not properly exited. Hope that helps your tests... -------- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 12/28/06, Guy Rouillier <[EMAIL PROTECTED]> wrote: I don't want to violate any license agreement by discussing performance, so I'll refer to a large

Re: [PERFORM] Pipelined functions in Postgres

I dont think so that will be possible using SETOF function ...You might have to partition the current query and this way can distribute the full load of the query if there is too much data invovled.Thanks, -- Shoaib MirEnterpriseDB (www.enterprisedb.com)On 9/20/06, Milen Kulev < [EMAIL PROTECTED]>

Re: [PERFORM] Pipelined functions in Postgres

I think pipelined functions are code you can pretend is a database table. For example you can do it like this in Oracle: select * from PLSQL_FUNCTION;You can achieve something similar in PostgreSQL using RETURN SETOF functions like this: CREATE OR REPLACE FUNCTION test_pipe (int)     RETURNS SETO