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
On Mar 26, 2010, at 5:25 PM, Scott Carey wrote:
Linux until recently does not account for shared memory properly in its swap
'aggressiveness' decisions.
Setting shared_buffers larger than 35% is asking for trouble.
You could try adjusting the 'swappiness' setting on the fly and seeing how
2010/3/28 Tadipathri Raghu traghu@gmail.com
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
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 for
2010/3/28 Tadipathri Raghu traghu@gmail.com
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
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
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.
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
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
Tadipathri Raghu traghu@gmail.com 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
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
Jeremy Harris j...@wizmail.org 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
2010/3/25 Robert Haas robertmh...@gmail.com:
On Wed, Mar 17, 2010 at 9:01 PM, Eger, Patrick pe...@automotive.com 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
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
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
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 on
16 matches
Mail list logo
