Horton

Re: ToDo List Item - System Table Index Clustering

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: saiken@quietlycompetent.com, Simone Aiken <saiken@ulfheim.net>, Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-01-19T22:43:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add new buffers_backend_fsync field to pg_stat_bgwriter.

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, on my machine pg_description is about 210K (per database) as of
>> HEAD. 90% of its contents are pg_proc entries, though I have no good
>> fix on how much of that is for internal-use-only functions. A very
>> rough estimate from counting pg_proc and pg_operator entries suggests
>> that the answer might be "about a third". So if we do what was said in
>> the above-cited thread, ie move existing comments to pg_operator and
>> add boilerplate ones to pg_proc, we probably would pay <100K for it.

> I guess that's not enormously expensive, but it's not insignificant
> either.  On my machine, a template database is 5.5MB.

The implementation I was thinking about was to have initdb run a SQL
command that would do something like

INSERT INTO pg_description
  SELECT oprcode, 'pg_proc'::regclass, 0, 'implementation of ' || oprname
  FROM pg_operator
  WHERE theres-not-already-a-description-of-the-oprcode-function

So it would be minimal work to either provide or omit the boilerplate
descriptions.  I think we can postpone the decision till we have a
closer fix on the number of entries we're talking about.

			regards, tom lane