On Mon, 29 Mar 2010, Tadipathri Raghu wrote:
As per the documentation, one page is 8kb, when i create a table with int as
one column its 4 bytes. If i insert 2000 rows, it should be in one page only
as its 8kb, but its extending vastly as expected. Example shown below,
taking the previous
Hi Mattew,
Thank you for the information.
Once again, I like to thank each and everyone in this thread for there
ultimate support.
Regards
Raghavendra
On Mon, Mar 29, 2010 at 4:47 PM, Matthew Wakeling matt...@flymine.orgwrote:
On Mon, 29 Mar 2010, Tadipathri Raghu wrote:
As per the
See http://www.postgresql.org/docs/current/static/storage-page-layout.html for
all of what is taking up the space. Short version:
Per block overhead is 24 bytes
Per row overhead is 23 bytes + some alignment loss + the null bitmap if you
have nullable columns
On Mon, Mar 29, 2010 at 8:24 AM,
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
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
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
15 matches
Mail list logo
