[PERFORM] Why Wal_buffer is 64KB

2010-03-25 Thread Tadipathri Raghu
Hi All, Can anybody clarify on this, why wal_buffer is 64kb and what is advantages and disadvantages in increasing or decreasing the wal_buffer. Regards Raghav

Re: [PERFORM] Why Wal_buffer is 64KB

2010-03-25 Thread Tadipathri Raghu
Hi Pierre, First of all , I Thank all for sharing the information on this Issue. On Thu, Mar 25, 2010 at 11:44 PM, Pierre C wrote: > > If you do large transactions, which emits large quantities of xlog, be > aware that while the previous xlog segment is being fsynced, no new writes > happen to

[PERFORM] Optimizer showing wrong rows in plan

2010-03-27 Thread Tadipathri Raghu
Hi All, Example on optimizer === postgres=# create table test(id int); CREATE TABLE postgres=# insert into test VALUES (1); INSERT 0 1 postgres=# select * from test; id 1 (1 row) postgres=# explain select * from test; QUERY PLAN --

Re: [PERFORM] Optimizer showing wrong rows in plan

2010-03-28 Thread Tadipathri Raghu
:32 PM, Szymon Guz wrote: > 2010/3/28 Tadipathri Raghu > > Hi All, >> >> Example on optimizer >> === >> postgres=# create table test(id int); >> CREATE TABLE >> postgres=# insert into test VALUES (1); >> INSERT 0 1 >>

Re: [PERFORM] Optimizer showing wrong rows in plan

2010-03-28 Thread Tadipathri Raghu
e have only one in it. Thanks if we have proper explination on this.. Regards Raghavendra On Sun, Mar 28, 2010 at 12:59 PM, Szymon Guz wrote: > > > 2010/3/28 Tadipathri Raghu > >> Hi Guz, >> >> Thank you for the prompt reply. >> >> >>> No,

Re: [PERFORM] Optimizer showing wrong rows in plan

2010-03-28 Thread Tadipathri Raghu
. Clarify me on this Please. Regards Raghavendra On Sun, Mar 28, 2010 at 2:06 PM, Gary Doades wrote: > On 28/03/2010 8:33 AM, Tadipathri Raghu wrote: > > Hi Guz, > > >> It is assuming that there are 2400 rows in this table. Probably you've >> deleted some rows

Re: [PERFORM] Optimizer showing wrong rows in plan

2010-03-28 Thread Tadipathri Raghu
Hi Tom, Thank for the update. > IIRC, it will set the relpages/reltuples counts (though not any > more-complex statistics); but only if the table is found to not be > completely empty. Again, this is a behavior designed with common > usage patterns in mind, to not set relpages/reltuples to zero

Re: [PERFORM] Why Wal_buffer is 64KB

2010-03-28 Thread Tadipathri Raghu
Hi All, Thank you for all the support. I have noticed one more thing here, that if you turn off the fsync and try to run the transaction than its breaking the currnet filenode and generating another filenode. Is it true that whenever you turn off or on the fsync the filenode will break and create

Re: [PERFORM] Why Wal_buffer is 64KB

2010-03-29 Thread Tadipathri Raghu
2:00 AM, Tadipathri Raghu > wrote: > > Hi All, > > > > Thank you for all the support. > > > > I have noticed one more thing here, that if you turn off the fsync and > try > > to run the transaction than its breaking the currnet filenode and > generating >