<?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>Pablowe &#187; Postgres</title>
	<atom:link href="http://www.pablowe.net/category/postgres/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pablowe.net</link>
	<description>%&#62; random tech;</description>
	<lastBuildDate>Wed, 20 Feb 2013 22:42:40 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
		<item>
		<title>Predicting Postgres Performance By Looking At Old MySQL Bugs</title>
		<link>http://www.pablowe.net/2012/09/predicting-postgres-performance-by-looking-at-old-mysql-bugs/</link>
		<comments>http://www.pablowe.net/2012/09/predicting-postgres-performance-by-looking-at-old-mysql-bugs/#comments</comments>
		<pubDate>Thu, 20 Sep 2012 17:54:09 +0000</pubDate>
		<dc:creator>rlowe</dc:creator>
				<category><![CDATA[Performance]]></category>
		<category><![CDATA[Postgres]]></category>

		<guid isPermaLink="false">http://www.pablowe.net/?p=935</guid>
		<description><![CDATA[While putting PostgreSQL 9.2 through it&#8217;s paces, I noticed some behavior that was eerily familiar. Back in January of 2006, Peter Zaitsev opened a bug against MySQL 4.1 that complained of a comparison of an out-of-range constant triggering a key lookup (later distilled to a feature request to &#8220;statically evaluate predicates using implicit type constraints&#8221;). [...]]]></description>
		<wfw:commentRss>http://www.pablowe.net/2012/09/predicting-postgres-performance-by-looking-at-old-mysql-bugs/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>pg_stat_activity shows future queries!</title>
		<link>http://www.pablowe.net/2012/09/pg_stat_activity-shows-future-queries/</link>
		<comments>http://www.pablowe.net/2012/09/pg_stat_activity-shows-future-queries/#comments</comments>
		<pubDate>Wed, 12 Sep 2012 01:53:52 +0000</pubDate>
		<dc:creator>rlowe</dc:creator>
				<category><![CDATA[Postgres]]></category>
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.pablowe.net/?p=914</guid>
		<description><![CDATA[This morning I was working on getting some statistics on average transaction open time on a relatively underutilized host when I noticed some oddities. Periodically, I would see that my average duration of open transactions would dip below zero seconds. As I looked into it, I came across the following result from a simple query [...]]]></description>
		<wfw:commentRss>http://www.pablowe.net/2012/09/pg_stat_activity-shows-future-queries/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Postgres unaware of it&#8217;s own connection limits?</title>
		<link>http://www.pablowe.net/2012/09/postgres-unaware-of-its-own-connection-limits/</link>
		<comments>http://www.pablowe.net/2012/09/postgres-unaware-of-its-own-connection-limits/#comments</comments>
		<pubDate>Thu, 06 Sep 2012 04:48:55 +0000</pubDate>
		<dc:creator>rlowe</dc:creator>
				<category><![CDATA[Bug]]></category>
		<category><![CDATA[Postgres]]></category>
		<category><![CDATA[PostgreSQL]]></category>

		<guid isPermaLink="false">http://www.pablowe.net/?p=904</guid>
		<description><![CDATA[Normally I&#8217;d just file a bug with something like this, but there&#8217;s no PostgreSQL bug tracker. So I&#8217;m left with a blog post &#8230; I was doing some testing with PostgreSQL memory usage and needed to know what the maximum value of max_connections is. So naturally, I consulted the documentation. It stated that this was [...]]]></description>
		<wfw:commentRss>http://www.pablowe.net/2012/09/postgres-unaware-of-its-own-connection-limits/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>Approximating Postgres Replication Delay</title>
		<link>http://www.pablowe.net/2012/08/approximating-postgres-replication-delay/</link>
		<comments>http://www.pablowe.net/2012/08/approximating-postgres-replication-delay/#comments</comments>
		<pubDate>Thu, 30 Aug 2012 23:32:59 +0000</pubDate>
		<dc:creator>rlowe</dc:creator>
				<category><![CDATA[Postgres]]></category>
		<category><![CDATA[Replication]]></category>

		<guid isPermaLink="false">http://www.pablowe.net/?p=896</guid>
		<description><![CDATA[Coming from the MySQL world, I&#8217;m used to being able to easily determine the replication delay (in seconds) via the SHOW SLAVE STATUS command: mysql> show slave status\G *************************** 1. row *************************** ... Seconds_Behind_Master: 0 ... 1 row in set (0.00 sec) Unfortunately, there is no such comparable command in PostgreSQL. The official docs propose [...]]]></description>
		<wfw:commentRss>http://www.pablowe.net/2012/08/approximating-postgres-replication-delay/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>PostgreSQL 9.1 max_wal_senders &#8211; The Missing Documentation</title>
		<link>http://www.pablowe.net/2012/08/postgresql-9-1-max_wal_senders-the-missing-documentation/</link>
		<comments>http://www.pablowe.net/2012/08/postgresql-9-1-max_wal_senders-the-missing-documentation/#comments</comments>
		<pubDate>Thu, 09 Aug 2012 04:30:12 +0000</pubDate>
		<dc:creator>rlowe</dc:creator>
				<category><![CDATA[Postgres]]></category>

		<guid isPermaLink="false">http://www.pablowe.net/?p=858</guid>
		<description><![CDATA[When setting up Log Shipping or Streaming Replication with PostgreSQL 9.1, you&#8217;ll inevitably come across the max_wal_senders configuration variable. The docs on this are sparse, saying only: &#8220;Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients (i.e., the maximum number of simultaneously running WAL sender processes). The default is [...]]]></description>
		<wfw:commentRss>http://www.pablowe.net/2012/08/postgresql-9-1-max_wal_senders-the-missing-documentation/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
