Skip site navigation (1) Skip section navigation (2)

Re: 27 second plan times

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 27 second plan times
Date: 2007-04-22 02:34:57
Message-ID: 16495.1177209297@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
I wrote:
> I'm still feeling a bit annoyed with the behavior of the stats machinery
> (pgstat_initstats and related macros).
> ... That means more UDP traffic and more work for
> the stats collector.  gprof won't show the resulting overhead since
> it doesn't know anything about kernel-level overhead or activity in the
> stats collector.  (Hm, might be able to measure it in oprofile
> though...)

I spent some time with oprofile and couldn't muster any evidence
suggesting that this was accounting for more than 1% or so of total
runtime.  So for the moment I'll leave it alone.  It might eventually
become worth worrying about, though.

The thing I saw as being more interesting than the tabstat overhead
is that the planner does RelationGetNumberOfBlocks (ie, an lseek kernel
call) on every child rel ... and would do it on every index of every
child rel, too, if the example had any.  It would be nice if we could
postpone all of the work of get_relation_info() until after we've
checked for constraint exclusion.  This looks like it'd require some
nontrivial refactoring though --- in particular, I'm not sure how we'd
handle the total_table_pages calculation.

If you're satisfied with the performance as it now stands, let's leave
this for the maybe-do-someday list.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-22 03:52:40
Subject: pgsql: Remove some of the most blatant brain-fade in the recent guc
Previous:From: Nabucodonosor CoutinhoDate: 2007-04-22 02:11:34
Subject: Fwd: PgAdmin pt_BR traduction

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group