Hi,


While monitioring we noticed that there are no details in the pg_statistics
for a particular table. Can you let us know what might be the reason? Also
what steps can be taken care for adding the statistics?

Note: The queries which are running on this table are taken longer time then
al the other queries.


Thanks,
Nimesh.

Nimesh Satam wrote:
> While monitioring we noticed that there are no details in the pg_statistics
> for a particular table. Can you let us know what might be the reason? Also
> what steps can be taken care for adding the statistics?

Have you ANALYZEd the table?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Heikki,


Thank you for replying.

We have already used analyze command on the table.
We have also ran the vacuum analyze command.


But they are not helping.

Thanks,
Nimesh.


On 6/11/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
>
> Nimesh Satam wrote:
> > While monitioring we noticed that there are no details in the
> pg_statistics
> > for a particular table. Can you let us know what might be the reason?
> Also
> > what steps can be taken care for adding the statistics?
>
> Have you ANALYZEd the table?
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>

On Mon, Jun 11, 2007 at 02:28:32PM +0530, Nimesh Satam wrote:
> We have already used analyze command on the table.
> We have also ran the vacuum analyze command.
>
> But they are not helping.

Is there any data in the table? What does ANALYZE VERBOSE or VACUUM
ANALYZE VERBOSE show for this table? Is there any chance that
somebody set all of the columns' statistics targets to zero?

--
Michael Fuhr

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Michael,


Following is the output of Vacuum analze on the same table:


*psql =# VACUUM ANALYZE verbose cam_attr;
INFO: vacuuming "public.cam_attr"
INFO: index "cam_attr_pk" now contains 11829 row versions in 63 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "cam_attr": found 0 removable, 11829 nonremovable row versions in 103
pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 236 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: analyzing "public.cam_attr"
INFO: "cam_attr": scanned 103 of 103 pages, containing 11829 live rows and
0 dead rows; 6000 rows in sample, 11829 estimated total rows
VACUUM
*

Also how do we check if the statistics are set to Zero for the table?

Regards,
Nimesh.


On 6/11/07, Michael Fuhr <mike@fuhr.org> wrote:
>
> On Mon, Jun 11, 2007 at 02:28:32PM +0530, Nimesh Satam wrote:
> > We have already used analyze command on the table.
> > We have also ran the vacuum analyze command.
> >
> > But they are not helping.
>
> Is there any data in the table? What does ANALYZE VERBOSE or VACUUM
> ANALYZE VERBOSE show for this table? Is there any chance that
> somebody set all of the columns' statistics targets to zero?
>
> --
> Michael Fuhr
>

On Mon, Jun 11, 2007 at 07:22:24PM +0530, Nimesh Satam wrote:
> INFO: analyzing "public.cam_attr"
> INFO: "cam_attr": scanned 103 of 103 pages, containing 11829 live rows and
> 0 dead rows; 6000 rows in sample, 11829 estimated total rows

Looks reasonable.

> Also how do we check if the statistics are set to Zero for the table?

SELECT attname, attstattarget
FROM pg_attribute
WHERE attrelid = 'public.cam_attr'::regclass
AND attnum > 0
AND NOT attisdropped;

If nobody has changed the statistics targets then they're all
probably -1. Negative attstattarget values mean to use the system
default, which you can see with:

SHOW default_statistics_target;

How exactly are you determining that no statistics are showing up
for this table? Are you running a query like the following?

SELECT *
FROM pg_stats
WHERE schemaname = 'public' AND tablename = 'cam_attr';

--
Michael Fuhr

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster