pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Is there an equivalent for Oracle's user_tables.num_rows
3+ messages / 2 participants
[nested] [flat]

* Is there an equivalent for Oracle's user_tables.num_rows
@ 2007-02-10 00:00 Virag Saksena <virag@auptyma.com>
  2007-02-10 00:45 ` Re: Is there an equivalent for Oracle's user_tables.num_rows Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 3+ messages in thread

From: Virag Saksena @ 2007-02-10 00:00 UTC (permalink / raw)
  To: pgsql-performance

All,
    I am looking to automate analyze table in my application.

I have some insert only tables in my application which I need to analyze as data grows.
Since the inserts are application controlled, I can choose to run analyze when I determine the
data has grown more than x% since last analyze.

However since users can truncate the tables too, I need to be able to tell the numbers of rows
in the table as perceived by the optimizer. 

I could not decipher a good way of telling the number of table rows from pg_stats/pg_statistics.

Does someone know of a way of telling what the optimizer believes the number of rows are ?

The tables in question have multi-column primary keys.

Regards,

Virag

^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Is there an equivalent for Oracle's user_tables.num_rows
  2007-02-10 00:00 Is there an equivalent for Oracle's user_tables.num_rows Virag Saksena <virag@auptyma.com>
@ 2007-02-10 00:45 ` Tom Lane <tgl@sss.pgh.pa.us>
  2007-02-10 01:08   ` Re: Is there an equivalent for Oracle's user_tables.num_rows Virag Saksena <virag@auptyma.com>
  0 siblings, 1 reply; 3+ messages in thread

From: Tom Lane @ 2007-02-10 00:45 UTC (permalink / raw)
  To: Virag Saksena <virag@auptyma.com>; +Cc: pgsql-performance

"Virag Saksena" <virag@auptyma.com> writes:
> Does someone know of a way of telling what the optimizer believes the =
> number of rows are ?

You're looking in the wrong place; see pg_class.relpages and reltuples.

But note that in recent releases neither one is taken as gospel.
Instead the planner uses the current physical table size in place of
relpages, and scales reltuples correspondingly.  So neither steady
growth nor truncation create a need for re-ANALYZE; at least not as long
as the other statistics don't change too much.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Is there an equivalent for Oracle's user_tables.num_rows
  2007-02-10 00:00 Is there an equivalent for Oracle's user_tables.num_rows Virag Saksena <virag@auptyma.com>
  2007-02-10 00:45 ` Re: Is there an equivalent for Oracle's user_tables.num_rows Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-02-10 01:08   ` Virag Saksena <virag@auptyma.com>
  0 siblings, 0 replies; 3+ messages in thread

From: Virag Saksena @ 2007-02-10 01:08 UTC (permalink / raw)
  To: pgsql-performance

Thanks, that is exactly what I was looking for

I know that number of rows may not be the best indicator, but it is a 
heuristic that can be tracked
easily, causing analyze for the first x insert events, and then only doing 
it only when an insert event causes
total rows to exceed y % of the optimizer perceived rows

Other more accurate heuristics like relative distribution of columns would 
be harder to track in the application,
and I'd rather let the database do that by issuing the analyze

Regards,

Virag

----- Original Message ----- 
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Virag Saksena" <virag@auptyma.com>
Cc: <pgsql-performance@postgresql.org>
Sent: Friday, February 09, 2007 4:45 PM
Subject: Re: [PERFORM] Is there an equivalent for Oracle's 
user_tables.num_rows


> "Virag Saksena" <virag@auptyma.com> writes:
>> Does someone know of a way of telling what the optimizer believes the =
>> number of rows are ?
>
> You're looking in the wrong place; see pg_class.relpages and reltuples.
>
> But note that in recent releases neither one is taken as gospel.
> Instead the planner uses the current physical table size in place of
> relpages, and scales reltuples correspondingly.  So neither steady
> growth nor truncation create a need for re-ANALYZE; at least not as long
> as the other statistics don't change too much.
>
> regards, tom lane
> 




^ permalink  raw  reply  [nested|flat] 3+ messages in thread


end of thread, other threads:[~2007-02-10 01:08 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-02-10 00:00 Is there an equivalent for Oracle's user_tables.num_rows Virag Saksena <virag@auptyma.com>
2007-02-10 00:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-02-10 01:08   ` Virag Saksena <virag@auptyma.com>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox