On Mon, Mar 29, 2010 at 12: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
> another filenode. Is it true that w
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
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
Reydan Cankur wrote:
1) For calculating time to get the TPS, is pgbench using the wall
clock time or cpu time?
2) How is TPS calculated?
Wall clock time.
TPS=transactions processed / (end time - start time)
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Suppor
Pierre C wrote:
If you realize you got a bloat problem, for instance due to a
misconfigured vacuum, use CLUSTER, which re-generates table AND index
data, and besides, having your table clustered on an index of your
choice can boost performance quite a lot in some circumstances.
8.2 is so old
2010/3/25 Robert Haas :
> On Wed, Mar 17, 2010 at 9:01 PM, Eger, Patrick wrote:
>> I'm running 8.4.2 and have noticed a similar heavy preference for
>> sequential scans and hash joins over index scans and nested loops. Our
>> database is can basically fit in cache 100% so this may not be
>> appli
Jeremy Harris writes:
> On 03/28/2010 05:27 PM, Tom Lane wrote:
>> This is intentional: the size estimates for a never-yet-analyzed
>> table are *not* zero. This is because people frequently create and load
>> up a table and then immediately query it without an explicit ANALYZE.
> Does the creat
On 03/28/2010 05:27 PM, Tom Lane wrote:
This is intentional: the size estimates for a never-yet-analyzed
table are *not* zero. This is because people frequently create and load
up a table and then immediately query it without an explicit ANALYZE.
Does the creation of an index also populate s
Tadipathri Raghu writes:
> Frankly speaking its a newly created table without any operation on it as
> you have seen the example. Then how come it showing those many rows where we
> have only one in it.
Yes. This is intentional: the size estimates for a never-yet-analyzed
table are *not* zero.
On 28/03/2010 10:07 AM, Tadipathri Raghu wrote:
Hi All,
I want to give some more light on this by analysing more like this
1. In my example I have created a table with one column as INT( which
occupies 4 bytes)
2. Initially it occupies one page of space on the file that is (8kb).
So, here is i
Op 28 mrt 2010, om 11:07 heeft Tadipathri Raghu het volgende geschreven:
Hi All,
I want to give some more light on this by analysing more like this
1. In my example I have created a table with one column as
INT( which occupies 4 bytes)
2. Initially it occupies one page of space on the fil
Hi All,
I want to give some more light on this by analysing more like this
1. In my example I have created a table with one column as INT( which
occupies 4 bytes)
2. Initially it occupies one page of space on the file that is (8kb).
So, here is it assuming these many rows may fit in this page.
Hi Guz,
> It is assuming that there are 2400 rows in this table. Probably you've
> deleted some rows from the table leaving just one.
Frankly speaking its a newly created table without any operation on it as
you have seen the example. Then how come it showing those many rows where we
have only
2010/3/28 Tadipathri Raghu
> Hi Guz,
>
> Thank you for the prompt reply.
>
>
>> No, the optimizer is not retrieving anything, it just assumes that there
>> are 2400 rows because that is the number of rows that exists in the
>> statictics for this table. The optimizer just tries to find the best p
Hi Guz,
Thank you for the prompt reply.
> No, the optimizer is not retrieving anything, it just assumes that there
> are 2400 rows because that is the number of rows that exists in the
> statictics for this table. The optimizer just tries to find the best plan
> and to optimize the query plan fo
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
> postgres=# select * from test;
> id
>
> 1
> (1 row)
> postgres=# explain select * from test;
>
16 matches
Mail list logo
