<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>select * from depesz; &#187; configuration</title>
	<atom:link href="http://www.depesz.com/tag/configuration/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.depesz.com</link>
	<description></description>
	<lastBuildDate>Mon, 07 May 2012 20:34:27 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Write Ahead Log + Understanding postgresql.conf: checkpoint_segments, checkpoint_timeout, checkpoint_warning</title>
		<link>http://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/</link>
		<comments>http://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 00:46:49 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[checkpoint]]></category>
		<category><![CDATA[checkpoint_segments]]></category>
		<category><![CDATA[checkpoint_timeout]]></category>
		<category><![CDATA[checkpoint_warning]]></category>
		<category><![CDATA[configuration]]></category>
		<category><![CDATA[guc]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[understanding]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2249</guid>
		<description><![CDATA[While there are some docs on it, I decided to write about it, in perhaps more accessible language &#8211; not as a developer, but as PostgreSQL user. Some parts (quite large parts) were described in one of my earlier posts, but I&#8217;ll try to concentrate on WAL itself, and show a bit more in here. [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/feed/</wfw:commentRss>
		<slash:comments>23</slash:comments>
		</item>
		<item>
		<title>Understanding postgresql.conf : work_mem</title>
		<link>http://www.depesz.com/2011/07/03/understanding-postgresql-conf-work_mem/</link>
		<comments>http://www.depesz.com/2011/07/03/understanding-postgresql-conf-work_mem/#comments</comments>
		<pubDate>Sun, 03 Jul 2011 20:40:29 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[configuration]]></category>
		<category><![CDATA[gin]]></category>
		<category><![CDATA[guc]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[understanding]]></category>
		<category><![CDATA[work_mem]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2218</guid>
		<description><![CDATA[For todays post in Understanding postgresql.conf series, I chose work_mem parameter. Documentation describes it as: Specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. The value defaults to one megabyte (1MB). Note that for a complex query, several sort or hash operations might [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/07/03/understanding-postgresql-conf-work_mem/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>Understanding postgresql.conf : checkpoint_completion_target</title>
		<link>http://www.depesz.com/2010/11/03/checkpoint_completion_target/</link>
		<comments>http://www.depesz.com/2010/11/03/checkpoint_completion_target/#comments</comments>
		<pubDate>Wed, 03 Nov 2010 11:57:19 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[checkpoint_completion_target]]></category>
		<category><![CDATA[configuration]]></category>
		<category><![CDATA[guc]]></category>
		<category><![CDATA[performance]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[tuning]]></category>
		<category><![CDATA[understanding]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1902</guid>
		<description><![CDATA[Starting new blog series &#8211; explanation of various configuration parameters. I will of course follow no schedule or order &#8211; if I&#8217;d had to &#8211; it would be my job, and in this way &#8211; it&#8217;s fun. First configuration parameter to write about is checkpoint_completion_target. First, let&#8217;s think about what checkpoint is. As you perhaps [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/11/03/checkpoint_completion_target/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; GUC per user and database</title>
		<link>http://www.depesz.com/2009/11/16/waiting-for-8-5-guc-per-user-and-database/</link>
		<comments>http://www.depesz.com/2009/11/16/waiting-for-8-5-guc-per-user-and-database/#comments</comments>
		<pubDate>Mon, 16 Nov 2009 10:47:12 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[configuration]]></category>
		<category><![CDATA[guc]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1543</guid>
		<description><![CDATA[On 7th of October Alvaro Herrera committed his own patch, which adds quite interesting possibilty: Log Message: ----------- Make it possibly to specify GUC params per user and per database. &#160; Create a new catalog pg_db_role_setting where they are now stored, and better encapsulate the code that deals with settings into its realm. The old [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/11/16/waiting-for-8-5-guc-per-user-and-database/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Getting session variables without touching postgresql.conf</title>
		<link>http://www.depesz.com/2009/08/20/getting-session-variables-without-touching-postgresql-conf/</link>
		<comments>http://www.depesz.com/2009/08/20/getting-session-variables-without-touching-postgresql-conf/#comments</comments>
		<pubDate>Thu, 20 Aug 2009 18:41:26 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[configuration]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[sessions]]></category>
		<category><![CDATA[sql]]></category>
		<category><![CDATA[stackoverflow]]></category>
		<category><![CDATA[variables]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1480</guid>
		<description><![CDATA[This post has been updated with new code that uses temporary table &#8211; the code is at the end of post! There was this question on Stack Overflow. For future reference: guy asked how to do session variables &#8211; i.e. something he could define once in session, and later reuse in standard sql queries &#8211; [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/08/20/getting-session-variables-without-touching-postgresql-conf/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; Add log_line_prefix placeholder %e to contain the current SQL state</title>
		<link>http://www.depesz.com/2009/07/04/waiting-for-8-5-add-log_line_prefix-placeholder-e-to-contain-the-current-sql/</link>
		<comments>http://www.depesz.com/2009/07/04/waiting-for-8-5-add-log_line_prefix-placeholder-e-to-contain-the-current-sql/#comments</comments>
		<pubDate>Sat, 04 Jul 2009 18:26:35 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[configuration]]></category>
		<category><![CDATA[logs]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1445</guid>
		<description><![CDATA[Also yesterday, and also Peter Eisentraut, committed patch by Guillaume Smet, which: Add log_line_prefix placeholder %e to contain the current SQL state &#160; Author: Guillaume Smet What exactly does it do, and how the state looks? Let&#8217;s find out. I defined log_line_prefix to be &#8216;%m %u@%d %p %r {%e} &#8216;. log_min_duration_statement was set to 0. [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/07/04/waiting-for-8-5-add-log_line_prefix-placeholder-e-to-contain-the-current-sql/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

