Thread: Re: [COMMITTERS] pgsql: Some further performance tweaks for planning large inheritance

Does this eliminate problems with using a large number of tablespaces?

---------------------------------------------------------------------------

Tom Lane wrote:
> Log Message:
> -----------
> Some further performance tweaks for planning large inheritance trees that
> are mostly excluded by constraints: do the CE test a bit earlier to save
> some adjust_appendrel_attrs() work on excluded children, and arrange to
> use array indexing rather than rt_fetch() to fetch RTEs in the main body
> of the planner.  The latter is something I'd wanted to do for awhile anyway,
> but seeing list_nth_cell() as 35% of the runtime gets one's attention.
>
> Modified Files:
> --------------
>     pgsql/src/backend/optimizer/path:
>         allpaths.c (r1.162 -> r1.163)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/allpaths.c.diff?r1=1.162&r2=1.163)
>         clausesel.c (r1.84 -> r1.85)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/clausesel.c.diff?r1=1.84&r2=1.85)
>         costsize.c (r1.180 -> r1.181)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/costsize.c.diff?r1=1.180&r2=1.181)
>     pgsql/src/backend/optimizer/plan:
>         createplan.c (r1.228 -> r1.229)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/createplan.c.diff?r1=1.228&r2=1.229)
>         planagg.c (r1.30 -> r1.31)
>         (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planagg.c.diff?r1=1.30&r2=1.31)
>         planmain.c (r1.99 -> r1.100)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planmain.c.diff?r1=1.99&r2=1.100)
>     pgsql/src/backend/optimizer/util:
>         pathnode.c (r1.138 -> r1.139)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/pathnode.c.diff?r1=1.138&r2=1.139)
>         plancat.c (r1.133 -> r1.134)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/plancat.c.diff?r1=1.133&r2=1.134)
>         relnode.c (r1.86 -> r1.87)
>         (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/relnode.c.diff?r1=1.86&r2=1.87)
>     pgsql/src/backend/utils/adt:
>         selfuncs.c (r1.232 -> r1.233)
>         (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/selfuncs.c.diff?r1=1.232&r2=1.233)
>     pgsql/src/include/nodes:
>         relation.h (r1.140 -> r1.141)
>         (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/relation.h.diff?r1=1.140&r2=1.141)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:
> Does this eliminate problems with using a large number of tablespaces?

No, it doesn't have anything particular to do with tablespaces.
It gets rid of some bottlenecks that become noticeable with a
large number of child tables.

            regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Does this eliminate problems with using a large number of tablespaces?
>
> No, it doesn't have anything particular to do with tablespaces.
> It gets rid of some bottlenecks that become noticeable with a
> large number of child tables.

Yes, but I thought the problem with many tablespaces was the cost of
referencing them as child tables.  Simon?

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +