From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing - V18 |
Date: | 2016-03-13 23:39:26 |
Message-ID: | 56E5FA2E.8080401@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/13/16 6:30 PM, Peter Geoghegan wrote:
> On Sat, Mar 12, 2016 at 5:21 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> Would the wiki be a good place for such tips? Not as formal as the
>> documentation, and more centralized (and editable) than a collection
>> of blog posts.
>
> That general direction makes sense, but I'm not sure if the Wiki is
> something that this will work for. I fear that it could become
> something like the TODO list page: a page that contains theoretically
> accurate information, but isn't very helpful. The TODO list needs to
> be heavily pruned, but that seems like something that will never
> happen.
>
> A centralized location for performance tips will probably only work
> well if there are still high standards that are actively enforced.
> There still needs to be tight editorial control.
I think there's ways to significantly restrict who can edit a page, so
this could probably still be done via the wiki. IMO we should also be
encouraging users to test various tips and provide feedback, so maybe a
wiki page with a big fat request at the top asking users to submit any
feedback about the page to -performance.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2016-03-14 00:20:50 | Re: WIP: Detecting SSI conflicts before reporting constraint violations |
Previous Message | Jim Nasby | 2016-03-13 23:32:38 | Re: Relation extension scalability |