Re: [GENERAL] Poor performance of btrfs with Postgresql

[Toby Corkindale]

On 22/04/11 12:39, mark wrote:

(Tested on Ubuntu Server - Maverick - Kernel 2.6.35-28)



Don't take this the wrong way - I applaud you asking for feedback. BTW ->
Have you seen Greg Smiths PG 9.0 high performance book ? it's got some
chapters dedicated to benchmarking.


I do have the book, actually; I wasn't referring to it for these quick 
tests though.



Do you have battery backed write cache and a 'real' hardware raid card?

> Not sure why your testing with raid 0, but that is just me.

In production, yes. On a development machine, no. (Also hence the raid-0 
-- this machine doesn't need to be highly reliable, and am more 
interested in higher performance.)



You also did not provide enough other details for it to be of interest to
many other people as a good data point. If you left all else at the defaults
then might just mention that.

Did you play with readahead ?


No, but that's a good suggestion.
Have you? How much difference has it made?

[snip]


How was the raid configured ? did you do stripe/block alignment ? might not
make a noticeable difference but if one is serious maybe it is a good habit
to get into. I haven't done as much tuning work as I should with xfs but a
primer can be found at :
http://oss.sgi.com/projects/xfs/training/xfs_slides_04_mkfs.pdf


Linux software RAID; stripe/blocks were aligned correctly for lvm and at 
least ext4; unsure about XFS, and I've blown that away by now so can't 
check. :/



Getting benches with pg 9 would also be interested because of the changes to
pgbench between 8.4 and 9.0, although at only about 230 tps I don't know how
much a difference you will see, since the changes only really show up when
you can sustain at a much higher tps rate.


Well, closer to 2400 TPS actually, including the runs with barriers 
disabled.


I'll re-run the tests in May - by then ubuntu server will be out, and 
11.04 comes with a newer kernel that supposedly improves btrfs 
performance a bit (and ext4 slightly), and I'll also use PG 9.0



Knowing the PG config, would also be interesting, but with so few disks and
OS, xlogs, and data all being on the same disks  well yeah it's not a
superdome, but still would be worth noting on your blog for posterity sake.


Yeah; I know it's not a supercomputer setup, but I found it interesting 
to note that btrfs was such a poor contender -- that was the main point 
of my results. Also it's interesting to note that disabling barriers 
provides such a massive increase in performance.

(But with serious caveats if you are to do so safely)



Right now I wish I had a lot of time to dig into different XFS setups on
some of our production matching gear - but other projects have me too busy
and I am having trouble getting our QA people loan me gear for it.

Heck I haven't tested ext4 at all to speak of - so shame on me for that.


It seems worthwhile - it consistently ran slightly faster than XFS.


To loosely quote someone else I saw posting to a different thread a while
back "I would walk through fire for a 10% performance gain". IMO through
proper testing and benchmarking you can make sure you are not giving up 10%
(or more) performance where you don't have to - no matter what hardware you
are running.


I'm more worried about giving up 80% of my performance, as demonstrated 
by using sub-optimal filesystems, or sub-optimal options to the optimal 
filesystems!


Toby

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Feature Request, aggregate functions distinct on

[Rob Sargent]

On 04/26/2011 04:33 PM, Tom Lane wrote:

luda posch  writes:

I am not an expert on the official sql spec, but I think it would be useful
if distinct on() could be used within an aggregate when supplied with
another column name.  For example:



select sum(distinct on(id) order_price) from order_table;
select sum(distinct on(email_address) bounce_count) from email_bounces;
select sum(distinct on(county) area) from state_county_area;


Use another level of sub-select, eg

select sum(order_price) from
   (select distinct on(id) order_price from order_table ...) ss;

The usefulness of this doesn't really seem high enough to justify
inventing and maintaining a more compact way to handle it.

regards, tom lane

I thing OP was hoping for tuples of email, bounceCount. I don't read 
your sub-select as providing this?


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Feature Request, aggregate functions distinct on

[Tom Lane]

luda posch  writes:
> I am not an expert on the official sql spec, but I think it would be useful
> if distinct on() could be used within an aggregate when supplied with
> another column name.  For example:

> select sum(distinct on(id) order_price) from order_table;
> select sum(distinct on(email_address) bounce_count) from email_bounces;
> select sum(distinct on(county) area) from state_county_area;

Use another level of sub-select, eg

select sum(order_price) from
  (select distinct on(id) order_price from order_table ...) ss;

The usefulness of this doesn't really seem high enough to justify
inventing and maintaining a more compact way to handle it.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Feature Request, aggregate functions distinct on

[luda posch]

I have used and it is quite useful the 'distinct' keyword within aggregate
functions.

I am not an expert on the official sql spec, but I think it would be useful
if distinct on() could be used within an aggregate when supplied with
another column name.  For example:

select sum(distinct on(id) order_price) from order_table;
select sum(distinct on(email_address) bounce_count) from email_bounces;
select sum(distinct on(county) area) from state_county_area;

Perhaps my examples are a bit silly.  Realistically speaking, if I were
designing any of these hypothetical tables, I would design them so that the
"distinct on" wouldn't be necessary, as if it kind of redundant (in a
perfect database schema), but I have been thrown into very poorly designed
database schemas (has anyone ever had to develop for a firm that used the
"Interspire Email Marketer") where the "distinct on" syntax would have made
some monstrous queries a lot more compact and easy to maintain.  Aside from
the benefits of making an unweildy database easier to navigate, I'm sure
there are other creative uses more "elogant".

At any rate, what I am suggesting may be inherently impossible or require
some major recoding, I'd still be curious to know.

Respond with thoughts, comments, concerns.

Radmilla

Re: [GENERAL] Partial Index [WHERE col IN ('A','B')] Planner Anomalies

[Tom Lane]

"David Johnston"  writes:
> If I explain the above query multiple times (without any data changes) I get
> either of the two query plans / the Bitmap Heap one more often.  If I
> analyze the table I immediately get the "Index Scan" plan first but
> subsequent explains revert to switching between the two However, if I run
> any other query but the three-criteria query then the flipping behavior
> observed stops and the "Bitmap Heap" plan becomes the dominant plan.  The 

Hmmm ... I'm seeing some very odd behavior here too.  I suspect there is
some use-of-uninitialized-memory in there.  After several false starts
I have a script that reliably reproduces the change of behavior in
(debug builds of) both HEAD and 9.0:

drop table if exists taskinstance;

create table taskinstance (ti_status varchar, ti_creationtimestamp timestamptz);
create index ti_sortedstatus on taskinstance (ti_status, ti_creationtimestamp);
create index ti_active on taskinstance (ti_status) WHERE ti_status IN 
('ACTIVE', 'DISPATCHED', 'FAILURE');

vacuum taskinstance;

\c -

EXPLAIN SELECT * FROM taskinstance WHERE ti_status IN ('ACTIVE', 'DISPATCHED', 
'FAILURE');
EXPLAIN SELECT * FROM taskinstance WHERE ti_status IN ('ACTIVE', 'DISPATCHED', 
'FAILURE');
EXPLAIN SELECT * FROM taskinstance WHERE ti_status IN ('ACTIVE', 'DISPATCHED', 
'FAILURE');

The first two EXPLAINs give a sane plan, the third one not so much.
Poking at it now.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[Carlos Mennens]

On Tue, Apr 26, 2011 at 4:34 PM, Alban Hertroys
 wrote:
> I don't know much about mediawiki (except for how to use it), but it's not 
> unusual for modern web-apps to have some functionality to dump their contents 
> in a consistently formatted file (often XML) that it can subsequently import 
> into a new environment. Might be worth looking into.

Yes MediaWiki can dump pages into XML but that's what scares me. It
does it in pages so I would have to dump every Wiki page into a
separate XML file rather than doing one huge Wiki dump. I guess I need
to check the MediaWiki forums and find out how I can export everything
into XML. But lets say I do export every thing to XML. Now I have XML
file(s) and a new database for MediaWiki. How do I get all the old
data on the new server? Do I do a fresh install 1st and let the
installer configure my database as the assigned role, then import the
XML data through the MediaWiki tool? I guess I should check their
forums.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[Alban Hertroys]

On 26 Apr 2011, at 19:24, Carlos Mennens wrote:

> We've been using a Wiki server at the office for years. It was
> originally configured to use MySQL and finally after 8+ years we're
> moving the Wiki to a new platform of hardware. My question is the Wiki
> software (MediaWiki) is the only thing still tied to and using MySQL
> which we want to decommission but we've been using it for years so I'm
> worried we will lose the data. I've done some Google'ing to find out
> how can I change the MySQL database dump and successfully export it
> into my new PostgreSQL database however I don't know how practical or
> recommended this process is. I found sites like the following:


I don't know much about mediawiki (except for how to use it), but it's not 
unusual for modern web-apps to have some functionality to dump their contents 
in a consistently formatted file (often XML) that it can subsequently import 
into a new environment. Might be worth looking into.

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,4db72c7511671681815569!



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[John R Pierce]

On 04/26/11 12:24 PM, Carlos Mennens wrote:


I tried running the tool as suggested before and unless I'm doing
something wrong, I have no idea why it didn't work:

[root@db_old postgres]# pwd
/var/www/html/int/main/wiki/maintenance/postgres

[root@db_old postgres]# ls -l
total 60
drwxr-xr-x 2 root root  4096 Jul 13  2009 archives
-rw-r--r-- 1 root root 13988 Mar 12  2009 compare_schemas.pl
-rw-r--r-- 1 root root 14063 Nov 22  2008 mediawiki_mysql2postgres.pl
-rw-r--r-- 1 root root 23596 Mar 19  2009 tables.sql

[root@db_old postgres]# sh mediawiki_mysql2postgres.pl
mediawiki_mysql2postgres.pl: line 12: use: command not found
mediawiki_mysql2postgres.pl: line 13: use: command not found
mediawiki_mysql2postgres.pl: line 14: use: command not found
mediawiki_mysql2postgres.pl: line 15: use: command not found
mediawiki_mysql2postgres.pl: line 17: syntax error near unexpected token `('
mediawiki_mysql2postgres.pl: line 17: `use vars qw(%table %tz %special
@torder $COM);'


wild guess says, use perl, not sh to run a .pl



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[Carlos Mennens]

On Tue, Apr 26, 2011 at 3:06 PM, Greg Sabino Mullane  wrote:
> Correct. Keep in mind I don't think the XML route will convert the users
> table, just the wiki data itself. As someone else mentioned, the
> wiki itself will work fine, but support for any MediaWiki extensions
> is hit or miss because MediaWiki was a MySQL only shop for so long
> (and Wikimedia still uses it, and they influence a lot of the MW
> development).

So what is the ideal or best suggested approach on tackling this task?
I built the new Apache server and installed the new (latest) version
of MediaWiki on it. I then pointed the installation of the new server
to my existing PostgreSQL database server. I created a user and
database for MediaWiki to use but it self generated a new table schema
during the installation. Should I proceed or do I somehow need to
blast what the new installation did and migrate my old data in it's
place. I guess there just isn't a clean understanding on my part on
what I need to do in what particular order.

I tried running the tool as suggested before and unless I'm doing
something wrong, I have no idea why it didn't work:

[root@db_old postgres]# pwd
/var/www/html/int/main/wiki/maintenance/postgres

[root@db_old postgres]# ls -l
total 60
drwxr-xr-x 2 root root  4096 Jul 13  2009 archives
-rw-r--r-- 1 root root 13988 Mar 12  2009 compare_schemas.pl
-rw-r--r-- 1 root root 14063 Nov 22  2008 mediawiki_mysql2postgres.pl
-rw-r--r-- 1 root root 23596 Mar 19  2009 tables.sql

[root@db_old postgres]# sh mediawiki_mysql2postgres.pl
mediawiki_mysql2postgres.pl: line 12: use: command not found
mediawiki_mysql2postgres.pl: line 13: use: command not found
mediawiki_mysql2postgres.pl: line 14: use: command not found
mediawiki_mysql2postgres.pl: line 15: use: command not found
mediawiki_mysql2postgres.pl: line 17: syntax error near unexpected token `('
mediawiki_mysql2postgres.pl: line 17: `use vars qw(%table %tz %special
@torder $COM);'

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[Greg Sabino Mullane]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


> Just to be clear and make sure I understand correctly, I can export
> the Wiki info using the MediaWiki XML export tool (which I found) or I
> can try to use the MediaWiki tool referenced as
> 'mediawiki_mysql2postgres.pl', right? I think from reading the
> options, I should try the XML export 1st.

Correct. Keep in mind I don't think the XML route will convert the users 
table, just the wiki data itself. As someone else mentioned, the 
wiki itself will work fine, but support for any MediaWiki extensions 
is hit or miss because MediaWiki was a MySQL only shop for so long 
(and Wikimedia still uses it, and they influence a lot of the MW 
development).

- -- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201104261505
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAk23F70ACgkQvJuQZxSWSsgzxgCg3sdCbLN4dqqK7xwmDBufgVoj
Zq0AoLT7VMRG7U2VhGHgBmHmR3eGuh0o
=p0Gv
-END PGP SIGNATURE-



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Partial Index [WHERE col IN ('A','B')] Planner Anomalies

[David Johnston]

Hi,

 

I have the following query:

 

EXPLAIN SELECT * FROM taskinstance WHERE ti_status IN ('ACTIVE',
'DISPATCHED', 'FAILURE');

 

With two indices:

ti_active. partial index over (ti_status) WHERE ti_status IN
('ACTIVE','DISPATCHED','FAILURE')

ti_sortedstatus. full index over (ti_status, ti_creationtimestamp)

 

If I explain the above query multiple times (without any data changes) I get
either of the two query plans / the Bitmap Heap one more often.  If I
analyze the table I immediately get the "Index Scan" plan first but
subsequent explains revert to switching between the two However, if I run
any other query but the three-criteria query then the flipping behavior
observed stops and the "Bitmap Heap" plan becomes the dominant plan.  The 

 

QUERY PLAN

Bitmap Heap Scan on taskinstance  (cost=115.87..135.83 rows=2336 width=723)

  Recheck Cond: (((ti_status)::text = ANY
('{ACTIVE,DISPATCHED,FAILURE}'::text[])) AND ((ti_status)::text = ANY
('{ACTIVE,DISPATCHED,FAILURE}'::text[])))

  ->  BitmapAnd  (cost=115.87..115.87 rows=5 width=0)

->  Bitmap Index Scan on ti_active_dispatch_failed_tasks_idx
(cost=0.00..47.94 rows=2336 width=0)

->  Bitmap Index Scan on ti_sortedstatus_idx  (cost=0.00..66.52
rows=2336 width=0)

  Index Cond: ((ti_status)::text = ANY
('{ACTIVE,DISPATCHED,FAILURE}'::text[]))

 

QUERY PLAN

Index Scan using ti_active_dispatch_failed_tasks_idx on taskinstance
(cost=0.00..402.03 rows=2348 width=718)

 

In a total table size of 1.2M records the partial index covers around 2300

 

Now, if I keep the IN construct but only list one of the options (any one) I
get the following:

 

QUERY PLAN

Index Scan using ti_active_dispatch_failed_tasks_idx on taskinstance
(cost=0.00..466.44 rows=2868 width=725)

  Index Cond: ((ti_status)::text = 'FAILURE'::text) --works for 'ACTIVE' and
'DISPATCHED' as well

 

If I include two of them I get the following results:

 

Active, Dispatched 

QUERY PLAN

Bitmap Heap Scan on taskinstance  (cost=8.52..12.53 rows=1 width=718)

  Recheck Cond: ((ti_status)::text = ANY ('{ACTIVE,DISPATCHED}'::text[]))

  ->  Bitmap Index Scan on ti_active_dispatch_failed_tasks_idx
(cost=0.00..8.52 rows=1 width=0)

Index Cond: ((ti_status)::text = ANY
('{ACTIVE,DISPATCHED}'::text[]))

 

Active, Failure ---

QUERY PLAN

Bitmap Heap Scan on taskinstance  (cost=111.51..123.49 rows=2020 width=718)

  Recheck Cond: (((ti_status)::text = ANY
('{ACTIVE,DISPATCHED,FAILURE}'::text[])) AND ((ti_status)::text = ANY
('{ACTIVE,FAILURE}'::text[])))

  ->  BitmapAnd  (cost=111.51..111.51 rows=3 width=0)

->  Bitmap Index Scan on ti_active_dispatch_failed_tasks_idx
(cost=0.00..46.36 rows=2020 width=0) <

   ->  Bitmap Index Scan on ti_sortedstatus_idx  (cost=0.00..63.89
rows=2020 width=0) 

  Index Cond: ((ti_status)::text = ANY
('{ACTIVE,FAILURE}'::text[]))

 

Dispatched, Failure --

QUERY PLAN

Bitmap Heap Scan on taskinstance  (cost=115.77..135.72 rows=2348 width=718)

  Recheck Cond: (((ti_status)::text = ANY
('{ACTIVE,DISPATCHED,FAILURE}'::text[])) AND ((ti_status)::text = ANY
('{DISPATCHED,FAILURE}'::text[])))

  ->  BitmapAnd  (cost=115.77..115.77 rows=5 width=0)

->  Bitmap Index Scan on ti_active_dispatch_failed_tasks_idx
(cost=0.00..48.00 rows=2348 width=0) <<<

->  Bitmap Index Scan on ti_sortedstatus_idx  (cost=0.00..66.35
rows=2348 width=0) <<<

  Index Cond: ((ti_status)::text = ANY
('{DISPATCHED,FAILURE}'::text[]))

 

In the double and single criteria cases I get the same plan each time -
regardless of whether I run ANALYZE.

 

With the double-conditions the inclusion of "FAILURE" seems to confuse the
planner but the single condition plan for FAILURE works as expected.

 

The documentation is unclear on how the use of "IN ()" affects the query
planner.  At a basic level IN becomes (= OR =) which are both simple
conditionals/logic elements so it should work properly.  Also, if the
planner recognizes that the partial index is sufficient to cover the WHERE
clause why would it want to bring in a full index that is, by definition,
redundant?

 

I guess if you are not evaluating the WHERE clause the two-constraint
versions likely would work oddly (and they do for ACTIVE/DISPATCHED if I
reverse the order of the two items) but the three-constraint version
occasionally works and the one-constraints versions always work even though
they too do not match the original index where clause.

 

Nothing of a critical nature here but figured I'd report what I am seeing.
I can probably drop some constraints( and some data ) if you want to see the
"taskinstance" table; and I will happily provide whatever configuration info
you ask for.

 

Running 9.0.3 Windows  7 64-bit

 

Thanks,

 

David Johnston

 

 

Re: [GENERAL] Help - corruption issue?

[Tomas Vondra]

Dne 26.4.2011 14:41, Phoenix Kiula napsal(a):
> On Tue, Apr 26, 2011 at 3:24 PM, Scott Marlowe  
> wrote:
>> Are you sure you're getting all the data out of the source (broken)
>> database you think you are?  Are you sure those rows are in the dump?
> 
> 
> 
> Actually I am not. Some rows are missing.
> 
> Will a COUNT(*) on the two databases -- old and new -- be sufficient
> and reliable information about the number of rows that went AWOL?

That should give us at least some idea if the copy worked. Have you
checked the postmaster.log (and kernel log in /var/log/messages) why the
new DB crashed when you do "SELECT * FROM mytable LIMIT 1" (as TL
recommended yesterday)?

Tomas

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Help - corruption issue?

[Tomas Vondra]

Dne 26.4.2011 04:50, Phoenix Kiula napsal(a):
> Tomas, the line where it crashed, here are the 10 or so lines around it:
> 
>> > head -15272350 /backup/links/links_all.txt | tail -20

No, those lines are before the one that causes problems - line number is
15272357, and you've printed just 15272350 lines using head. Do this

$ head -15272367 /backup/links/links_all.txt | tail -20

That should give us 10 lines before, 10 lines after.

Tomas.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] "pg_control version number" after 9.0.4 installation

[Tom Lane]

"Carlos Sotto Maior \(SIM\)"  writes:
> After installing 9.0.4 I noticed that I get “pg_control version number =
> 903” when pg_controldata is run.

Those numbers are unrelated.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PG 9.0 - Default postgresql.conf?

[John R Pierce]

On 04/26/11 10:59 AM, Phoenix Kiula wrote:

How can I check what the problem is? I don't see any errors at least
on the command line.All I see is:



>  service postgresql restart

Stopping postgresql service:   [  OK  ]
Starting postgresql service:   [FAILED]



look in the server logfiles...   depending on your distribution, the 
system service startup script could be generating them various ways, 
I've seen $PGDATA/server.log and $PGDATA/pg_log/*.log commonly.




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[Carlos Mennens]

On Tue, Apr 26, 2011 at 1:44 PM, Greg Sabino Mullane  wrote:
> In general, yes. For your specific use case, it might be best to use
> MediaWiki's XML dump and restore. You could also use the conversion
> script that comes with MediaWiki, at:
>
> maintenance/postgres/mediawiki_mysql2postgres.pl
>
> It's a little old so I can't promise it will work with recent versions
> of MediaWiki, but should be enough to get you started testing.

Just to be clear and make sure I understand correctly, I can export
the Wiki info using the MediaWiki XML export tool (which I found) or I
can try to use the MediaWiki tool referenced as
'mediawiki_mysql2postgres.pl', right? I think from reading the
options, I should try the XML export 1st.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PG 9.0 - Default postgresql.conf?

[Andrew Sullivan]

On Wed, Apr 27, 2011 at 01:59:10AM +0800, Phoenix Kiula wrote:
 How can I check what the problem is? I don't see any errors at least
> on the command line.All I see is:
> 
> 
> > service postgresql restart
> Stopping postgresql service:   [  OK  ]
> Starting postgresql service:   [FAILED]

You probably want to look in the logs.  Under /var/log there should be
something -- if nowhere else, then in syslog.

A

-- 
Andrew Sullivan
a...@crankycanuck.ca

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[Steve Atkins]

On Apr 26, 2011, at 10:24 AM, Carlos Mennens wrote:

> We've been using a Wiki server at the office for years. It was
> originally configured to use MySQL and finally after 8+ years we're
> moving the Wiki to a new platform of hardware. My question is the Wiki
> software (MediaWiki) is the only thing still tied to and using MySQL
> which we want to decommission but we've been using it for years so I'm
> worried we will lose the data. I've done some Google'ing to find out
> how can I change the MySQL database dump and successfully export it
> into my new PostgreSQL database however I don't know how practical or
> recommended this process is. I found sites like the following:

It's certainly possible to dump a mysql database and import it into
postgresql, without too much difficulty in most cases. The problem
with porting the data tends to be bad data in the mysql database
that was allowed by mysql but is caught by postgresql.

Changing the app to support it is usually the bigger problem.

> 
> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL

At a quick glance, that doesn't look like a great resource. It's
suggesting using "password" rather than "md5" authentication,
amongst other things. There are also some obvious thinkos
or copy/paste problems (suggesting that '=' in mysql is equivalent
to '<>' in postgresql, for instance). While much of what it says
looks reasonable, I wouldn't rely on it.

http://www.mediawiki.org/wiki/Manual:PostgreSQL is a better
place to look, perhaps.

Most of the core mediawiki runs OK with postgresql, but most
addons don't.

You definitely want to set up a "test" wiki instance, running on
postgresql - that's the first thing to do regardless of how you
migrate the data.

Then doing an XML dump from your existing mediawiki
instance and importing it into your test instance will give
you an idea of how well that will work. If that's good enough,
you don't need to care about the underlying database.
There are several ways to import xml dumps, with different
tradeoffs - check the mediawiki docs.

> Can you guys tell me if this is something that will work? I don't mean
> the exact link above but just in general taking a database from MySQL
> and successfully migrating it for PostgreSQL use?
> 
> From what I can see in the MySQL database, there appears to be 43
> tables with lots of column data and who knows what else:

Cheers,
  Steve


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PG 9.0 - Default postgresql.conf?

[Phoenix Kiula]

On Wed, Apr 27, 2011 at 1:53 AM, Phoenix Kiula  wrote:
> On Wed, Apr 27, 2011 at 1:18 AM, Magnus Hagander  wrote:
>> On Tue, Apr 26, 2011 at 19:11, Phoenix Kiula  wrote:
>>> Hi,
>>>
>>> Is there any place I can download the default postgresql.conf that
>>> comes with 9.0?
>>
>> http://git.postgresql.org/gitweb?p=postgresql.git;a=blob_plain;f=src/backend/utils/misc/postgresql.conf.sample;h=a3880da7dac5d8ff55dc8f5f7a3f1fc8052627b0;hb=REL9_0_STABLE
>>
>> (note that initdb will make a few changes to it depending on your system)
>>
>> If you have installed PostgreSQL, you should also be able to locate a
>> postgresql.conf.sample file on your local system. Exactly were it is
>> depends on how you intalled PostgreSQL.
>
>
>
> Thanks Magnus. My PGSQL was installed on Linux using the Yum
> repositories. There's no file called *.conf.sample.
>
> What changes does initdb make -- can I make them by myself?
>



Btw, the default file is FAILING. The server does not restart.

How can I check what the problem is? I don't see any errors at least
on the command line.All I see is:


> service postgresql restart
Stopping postgresql service:   [  OK  ]
Starting postgresql service:   [FAILED]


Thanks!

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PG 9.0 - Default postgresql.conf?

[Phoenix Kiula]

On Wed, Apr 27, 2011 at 1:18 AM, Magnus Hagander  wrote:
> On Tue, Apr 26, 2011 at 19:11, Phoenix Kiula  wrote:
>> Hi,
>>
>> Is there any place I can download the default postgresql.conf that
>> comes with 9.0?
>
> http://git.postgresql.org/gitweb?p=postgresql.git;a=blob_plain;f=src/backend/utils/misc/postgresql.conf.sample;h=a3880da7dac5d8ff55dc8f5f7a3f1fc8052627b0;hb=REL9_0_STABLE
>
> (note that initdb will make a few changes to it depending on your system)
>
> If you have installed PostgreSQL, you should also be able to locate a
> postgresql.conf.sample file on your local system. Exactly were it is
> depends on how you intalled PostgreSQL.



Thanks Magnus. My PGSQL was installed on Linux using the Yum
repositories. There's no file called *.conf.sample.

What changes does initdb make -- can I make them by myself?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Switching Database Engines

[Greg Sabino Mullane]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
>
> Can you guys tell me if this is something that will work? I don't mean
> the exact link above but just in general taking a database from MySQL
> and successfully migrating it for PostgreSQL use?

In general, yes. For your specific use case, it might be best to use 
MediaWiki's XML dump and restore. You could also use the conversion 
script that comes with MediaWiki, at:

maintenance/postgres/mediawiki_mysql2postgres.pl

It's a little old so I can't promise it will work with recent versions 
of MediaWiki, but should be enough to get you started testing.

- -- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201104261344
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAk23BH4ACgkQvJuQZxSWSsgTOwCg7s0JXN8ZHrgng5F/c82+fbF6
Z3UAoLjBMqywR6ELmtGaJPz2IAiQoL2W
=SvR1
-END PGP SIGNATURE-



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Switching Database Engines

[Carlos Mennens]

We've been using a Wiki server at the office for years. It was
originally configured to use MySQL and finally after 8+ years we're
moving the Wiki to a new platform of hardware. My question is the Wiki
software (MediaWiki) is the only thing still tied to and using MySQL
which we want to decommission but we've been using it for years so I'm
worried we will lose the data. I've done some Google'ing to find out
how can I change the MySQL database dump and successfully export it
into my new PostgreSQL database however I don't know how practical or
recommended this process is. I found sites like the following:

http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL

Can you guys tell me if this is something that will work? I don't mean
the exact link above but just in general taking a database from MySQL
and successfully migrating it for PostgreSQL use?

>From what I can see in the MySQL database, there appears to be 43
tables with lots of column data and who knows what else:

mysql> show tables;
+--+
| Tables_in_wiki   |
+--+
| dp_archive   |
| dp_category  |
| dp_categorylinks |
| dp_change_tag|
| dp_externallinks |
| dp_filearchive   |
| dp_hitcounter|
| dp_image |
| dp_imagelinks|
| dp_interwiki |
| dp_ipblocks  |
| dp_ipblocks_old  |
| dp_job   |
| dp_langlinks |
| dp_logging   |
| dp_math  |
| dp_objectcache   |
| dp_oldimage  |
| dp_page  |
| dp_page_props|
| dp_page_restrictions |
| dp_pagelinks |
| dp_protected_titles  |
| dp_querycache|
| dp_querycache_info   |
| dp_querycachetwo |
| dp_recentchanges |
| dp_redirect  |
| dp_revision  |
| dp_searchindex   |
| dp_site_stats|
| dp_tag_summary   |
| dp_templatelinks |
| dp_text  |
| dp_trackbacks|
| dp_transcache|
| dp_updatelog |
| dp_user  |
| dp_user_groups   |
| dp_user_newtalk  |
| dp_valid_tag |
| dp_validate  |
| dp_watchlist |
+--+
43 rows in set (0.01 sec)

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PG 9.0 - Default postgresql.conf?

[Magnus Hagander]

On Tue, Apr 26, 2011 at 19:11, Phoenix Kiula  wrote:
> Hi,
>
> Is there any place I can download the default postgresql.conf that
> comes with 9.0?

http://git.postgresql.org/gitweb?p=postgresql.git;a=blob_plain;f=src/backend/utils/misc/postgresql.conf.sample;h=a3880da7dac5d8ff55dc8f5f7a3f1fc8052627b0;hb=REL9_0_STABLE

(note that initdb will make a few changes to it depending on your system)

If you have installed PostgreSQL, you should also be able to locate a
postgresql.conf.sample file on your local system. Exactly were it is
depends on how you intalled PostgreSQL.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] PG 9.0 - Default postgresql.conf?

[Phoenix Kiula]

Hi,

Is there any place I can download the default postgresql.conf that
comes with 9.0?

Thanks!

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL]auto vacuum during restore

[Vick Khera]

On Tue, Apr 26, 2011 at 12:59 PM, Guillaume Lelarge
wrote:

> > I do not believe analyze is part of the restore process.  You must
> > explicitly run it.
> >
>
> That's almost true. If autovacuum is on, it can start an ANALYZE on the
> big tables.
>
>
So that just means you need some luck of timing.  Not really "part of the
process" if you ask me.


>
>
> Depends of course on your settings (autovacuum on, stats collector on,
> etc.)
>

Re: [GENERAL]auto vacuum during restore

[Guillaume Lelarge]

Le 26/04/2011 18:38, Vick Khera a écrit :
> On Tue, Apr 26, 2011 at 11:36 AM, Willy-Bas Loos  wrote:
> 
>> I don't get it, they should have been analyzed at restore, should they not?
>>
> 
> I do not believe analyze is part of the restore process.  You must
> explicitly run it.
> 

That's almost true. If autovacuum is on, it can start an ANALYZE on the
big tables.

Depends of course on your settings (autovacuum on, stats collector on, etc.)


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Recover database from binary files

[Diogo Melo]

You were right. It was just a matter of set chown -R postgres.postgres
/var/lib/postgresql/8.3

:D :D :D

Case solved :D
Thanks a lot dude :D

Diogo Oliveira de Melo
Ciência da Computação
ICMC - USP São Carlos




On Tue, Apr 26, 2011 at 12:52 PM, Scott Marlowe wrote:

> On Tue, Apr 26, 2011 at 9:50 AM, Diogo Melo  wrote:
> > just tar -zcvf 8.3.tar.gz /mnt/sdf/var/lib/postgresql/8.3/
> > since i found a way to mount the partition on /mnt/sdf.
> > first I installed postgres on a virtual machine and then I extracted the
> > 8.3.tar.gz at /var/lib/postgresql . when i try to sh
> > /etc/init.d/postgresql-8.3 start it runs the command instantly but don't
> > launch anything.
> >
> > Is there a procedure to recover postgres databases on this occasions??
>
> Pretty much what you are doing is the procedure.  Check permissions on
> that folder, look in the postgresql logs, look in the system logs,
> etc.  It'll likely say something about wrong permissions, but that's
> just a guess.
>

[GENERAL] "pg_control version number" after 9.0.4 installation

[Carlos Sotto Maior (SIM)]

This is just a notice:

After installing 9.0.4 I noticed that I get “pg_control version number =
903” when pg_controldata is run.

 

Thanks,

 

Carlos Sotto Maior

+55 11 8244-7899

  cso...@sistemassim.com.br

 

Sistemas Sim Serviços e Tecnologia Ltda.

+55 11 5041-3086

Rua Tenente Gomes Ribeiro, 78

Vila Clementino (Próximo ao Metro Santa Cruz)

São Paulo - SP 

04038-040

 

Re: [GENERAL]auto vacuum during restore

[Vick Khera]

On Tue, Apr 26, 2011 at 11:36 AM, Willy-Bas Loos  wrote:

> I don't get it, they should have been analyzed at restore, should they not?
>

I do not believe analyze is part of the restore process.  You must
explicitly run it.

Re: [GENERAL] SSDs with Postgresql?

[Michael Nolan]

On Thu, Apr 21, 2011 at 10:33 AM, Florian Weimer  wrote:

> * Greg Smith:
>
> > The fact that every row update can temporarily use more than 8K means
> > that actual write throughput on the WAL can be shockingly large.  The
> > smallest customer I work with regularly has a 50GB database, yet they
> > write 20GB of WAL every day.  You can imagine how much WAL is
> > generated daily on systems with terabyte databases.
>
> Interesting.  Is there an easy way to monitor WAL traffic in away?  It
> does not have to be finegrained, but it might be helpful to know if
> we're doing 10 GB, 100 GB or 1 TB of WAL traffic on a particular
> database, should the question of SSDs ever come up.
>
> If you archive your WAL files, wouldn't that give you a pretty good
indication of write activity?

For example, yesterday I archived 74 WAL files, each 16MB.  That's about 1.2
gigabytes for a database that takes up about 58 GB.
--
Mike Nolan

Re: [GENERAL] optimizing a cpu-heavy query

[Tom Lane]

Joel Reymont  writes:
> I'm trying to optimize the following query that performs KL Divergence [1]. 
> As you can see the distance function operates on vectors of 150 floats. 

> CREATE OR REPLACE FUNCTION docs_within_distance(vec topics, threshold float) 
> RETURNS TABLE(id doc_id, distance float) AS $$
> BEGIN
>   RETURN QUERY
> SELECT * 
> FROM (SELECT doc_id, (SELECT sum(vec[i] * ln(vec[i] / topics[i])) 
>   FROM generate_subscripts(topics, 1) AS i
>   WHERE topics[i] > 0) AS distance
>   FROM docs) AS tab
> WHERE tab.distance <= threshold;
> END;
> $$ LANGUAGE plpgsql;

Yikes.  That sub-select is a mighty expensive way to compute the scalar
product.  Push it into a sub-function that takes the two arrays and
iterates over them with a for-loop.  For another couple orders of
magnitude, convert the sub-function to C code.  (I don't think you need
a whole data type, just a function that does the scalar product.)

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Recover database from binary files

[Scott Marlowe]

On Tue, Apr 26, 2011 at 9:50 AM, Diogo Melo  wrote:
> just tar -zcvf 8.3.tar.gz /mnt/sdf/var/lib/postgresql/8.3/
> since i found a way to mount the partition on /mnt/sdf.
> first I installed postgres on a virtual machine and then I extracted the
> 8.3.tar.gz at /var/lib/postgresql . when i try to sh
> /etc/init.d/postgresql-8.3 start it runs the command instantly but don't
> launch anything.
>
> Is there a procedure to recover postgres databases on this occasions??

Pretty much what you are doing is the procedure.  Check permissions on
that folder, look in the postgresql logs, look in the system logs,
etc.  It'll likely say something about wrong permissions, but that's
just a guess.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Recover database from binary files

[Diogo Melo]

just tar -zcvf 8.3.tar.gz /mnt/sdf/var/lib/postgresql/8.3/

since i found a way to mount the partition on /mnt/sdf.

first I installed postgres on a virtual machine and then I extracted the
8.3.tar.gz at /var/lib/postgresql . when i try to sh
/etc/init.d/postgresql-8.3 start it runs the command instantly but don't
launch anything.


Is there a procedure to recover postgres databases on this occasions??


Diogo Oliveira de Melo
Ciência da Computação
ICMC - USP São Carlos




On Tue, Apr 26, 2011 at 12:45 PM, Scott Marlowe wrote:

> On Tue, Apr 26, 2011 at 9:43 AM, Diogo Melo  wrote:
> > Hi,
> >
> > I can't boot the postgres server anymore. I just have access to the
> files,
> > like the /var/lib/postgresql/8.3 path, for example. I use debian and
> > postgresql-8.3 .
> >
> > I don't have any sql dump. How can I recover my databases with just the
> > binary files there?
> >
> > I tried copy the /var/lib/postgresql/8.3 to another a installation of
> > postgresql-8.3 on another server, but without success.
>
> How did you copy them?  What error(s) did you get?
>

[GENERAL] Fwd: Recover database from binary files

[Diogo Melo]

Diogo Oliveira de Melo
Ciência da Computação
ICMC - USP São Carlos




-- Forwarded message --
From: Diogo Melo 
Date: Tue, Apr 26, 2011 at 12:43 PM
Subject: Recover database from binary files
To: pgsql-general@postgresql.org


Hi,

I can't boot the postgres server anymore. I just have access to the files,
like the /var/lib/postgresql/8.3 path, for example. I use debian and
postgresql-8.3 .

I don't have any sql dump. How can I recover my databases with just the
binary files there?

I tried copy the /var/lib/postgresql/8.3 to another a installation of
postgresql-8.3 on another server, but without success.


Diogo Oliveira de Melo
Ciência da Computação
ICMC - USP São Carlos

Re: [GENERAL] Recover database from binary files

[Scott Marlowe]

On Tue, Apr 26, 2011 at 9:43 AM, Diogo Melo  wrote:
> Hi,
>
> I can't boot the postgres server anymore. I just have access to the files,
> like the /var/lib/postgresql/8.3 path, for example. I use debian and
> postgresql-8.3 .
>
> I don't have any sql dump. How can I recover my databases with just the
> binary files there?
>
> I tried copy the /var/lib/postgresql/8.3 to another a installation of
> postgresql-8.3 on another server, but without success.

How did you copy them?  What error(s) did you get?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Recover database from binary files

[Diogo Melo]

Hi,

I can't boot the postgres server anymore. I just have access to the files,
like the /var/lib/postgresql/8.3 path, for example. I use debian and
postgresql-8.3 .

I don't have any sql dump. How can I recover my databases with just the
binary files there?

I tried copy the /var/lib/postgresql/8.3 to another a installation of
postgresql-8.3 on another server, but without success.


Diogo Oliveira de Melo
Ciência da Computação
ICMC - USP São Carlos

Re: [GENERAL] tuning on ec2

[Scott Marlowe]

On Tue, Apr 26, 2011 at 9:34 AM, Joel Reymont  wrote:
>
> On Apr 26, 2011, at 4:31 PM, Scott Marlowe wrote:
>
>> It's a reasonable start.  However, if you consistently using less than
>> that in aggregate then lowering it is fine.
>
> Is there a way to tell if I consistently use less than that in aggregate?

Keep an eye on shr for postgres processes in top.   It should
eventually reach about the same size as your shared_buffers if you're
using it.  If it stays at 500M or something then you don't need as
much shared_buffers.

>> What's your work_mem and max_connections set to?
>
> I have the default settings, e.g. work_mem = 1MB and max_connections = 100.
>
> I'm looking to process 400 requests per second, though. What should I use for 
> the above?

Those settings are fine to start.  Look at connection pooling, as
having too many backends can cause the db to run slower.  Generally 2x
or so as many cores as you have is a good place to start with how many
connections to keep alive by the pooler.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL]auto vacuum during restore

[Willy-Bas Loos]

Hi,

i've tested on 8.3 and 8.4 and i found that autovacuum works during restore
uin my test scenario, which is:
a new database wit two tables. tab1 has 1M recs, tab2 has 10 recs.
When i drop the database and restore, pg_stat_all tables tells me good
estimations for the number of live tuples.

But on a copy of a live database (postgres 8.3), there are zeros for
n_live_tup on tables that do contain records.
When i do an ANALYZE (without vacuum) these remain 0. When i do VACUUM
ANALYZE, they are filled in correctly.

I don't get it, they should have been analyzed at restore, should they not?

Cheers,

WBL

---non default postgresql.conf settings below
$ grep ^[^#] /etc/postgresql/8.3/oz/postgresql.conf|grep -e ^[^[:space:]]
data_directory = '/data/postgresql/8.3/oz' # use data in another directory
hba_file = '/etc/postgresql/8.3/oz/pg_hba.conf' # host-based authentication
file
ident_file = '/etc/postgresql/8.3/oz/pg_ident.conf' # ident configuration
file
external_pid_file = '/var/run/postgresql/8.3-oz.pid' # write an extra PID
file
listen_addresses = '*' # what IP address(es) to listen on;
port = 5434 # (change requires restart)
max_connections = 100 # (change requires restart)
unix_socket_directory = '/var/run/postgresql' # (change requires restart)
tcp_keepalives_idle = 120 # TCP_KEEPIDLE, in seconds;
shared_buffers = 2048MB # min 128kB or max_connections*16kB
work_mem = 50MB # min 64kB
maintenance_work_mem = 200MB # min 1MB
max_fsm_pages = 300 # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 1 # min 100, ~70 bytes each
synchronous_commit = off # immediate fsync at commit
wal_writer_delay = 500ms # 1-1 milliseconds
commit_delay = 500 # range 0-10, in microseconds
effective_cache_size = 4096MB
default_statistics_target = 100 # range 1-1000
log_min_duration_statement = 30 # -1 is disabled, 0 logs all statements
log_line_prefix = '%t ip:%h ' # special values:
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'



-- 
"Patriotism is the conviction that your country is superior to all others
because you were born in it." -- George Bernard Shaw

Re: [GENERAL] tuning on ec2

[Joel Reymont]

On Apr 26, 2011, at 4:31 PM, Scott Marlowe wrote:

> It's a reasonable start.  However, if you consistently using less than
> that in aggregate then lowering it is fine.

Is there a way to tell if I consistently use less than that in aggregate?

> What's your work_mem and max_connections set to?

I have the default settings, e.g. work_mem = 1MB and max_connections = 100.

I'm looking to process 400 requests per second, though. What should I use for 
the above?

Thanks, Joel

--
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
-++---
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
-++---




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] tuning on ec2

[Scott Marlowe]

On Tue, Apr 26, 2011 at 8:59 AM, Joel Reymont  wrote:
> I'm running pgsql on an m1.large EC2 instance with 7.5gb available memory.
>
> The free command shows 7gb of free+cached. My understand from the docs is 
> that I should dedicate 1.75gb to shared_buffers (25%) and set 
> effective_cache_size to 7gb.
>
> Is this correct? I'm running 64-bit Ubuntu 10.10, e.g.

It's a reasonable start.  However, if you consistently using less than
that in aggregate then lowering it is fine.  What's your work_mem and
max_connections set to?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] tuning on ec2

[Joel Reymont]

I'm running pgsql on an m1.large EC2 instance with 7.5gb available memory. 

The free command shows 7gb of free+cached. My understand from the docs is that 
I should dedicate 1.75gb to shared_buffers (25%) and set effective_cache_size 
to 7gb. 

Is this correct? I'm running 64-bit Ubuntu 10.10, e.g. 

Linux ... 2.6.35-28-virtual #50-Ubuntu SMP Fri Mar 18 19:16:26 UTC 2011 x86_64 
GNU/Linux

Thanks, Joel

--
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
-++---
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
-++---




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 10 missing features

[Scott Marlowe]

On Tue, Apr 26, 2011 at 5:39 AM, Andrew Sullivan  wrote:

> In commercial development, this is where product development managers
> live.  They identify the meaning of the feature request, and then
> identify how the actual need (rather than the requested feature) can
> be addressed.

But there are also plenty of examples where this falls down.  I know
for years oracle refused to release a proper package for the client
side libs.  sqlplus has no command line history.  Luckily there's
rlwrap for that, but that's an example where you need an external
package to make Oracle come close to what's built into pgsql.  Sadly a
LOT of what a product manager is tasked with getting added to the
database is determined solely by its ability to generate more cash
flow, so often basic features like command line editing never get
done.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] optimizing a cpu-heavy query

[Joel Reymont]

Folks,

I'm trying to optimize the following query that performs KL Divergence [1]. As 
you can see the distance function operates on vectors of 150 floats. 

The query takes 12 minutes to run on an idle (apart from pgsql) EC2 m1 large 
instance with 2 million documents in the docs table. The CPU is pegged at 100% 
during this time. I need to be able to both process concurrent distance queries 
and otherwise use the database.

I have the option of moving this distance calculation off of PG but are there 
other options?

Is there anything clearly wrong that I'm doing here?

Would it speed things up to make the float array a custom data type backed by C 
code?

Thanks in advance, Joel

[1] http://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_divergence

---

CREATE DOMAIN topics AS float[150];
CREATE DOMAIN doc_id AS varchar(64);

CREATE TABLE docs
(
  id  serial,
  doc_id  doc_id NOT NULL PRIMARY KEY,
  topics  topics NOT NULL
);

CREATE OR REPLACE FUNCTION docs_within_distance(vec topics, threshold float) 
RETURNS TABLE(id doc_id, distance float) AS $$
BEGIN
RETURN QUERY
SELECT * 
FROM (SELECT doc_id, (SELECT sum(vec[i] * ln(vec[i] / topics[i])) 
  FROM generate_subscripts(topics, 1) AS i
  WHERE topics[i] > 0) AS distance
  FROM docs) AS tab
WHERE tab.distance <= threshold;
END;
$$ LANGUAGE plpgsql;


--
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
-++---
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
-++---




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] SSDs with Postgresql?

[Toby Corkindale]

- Original Message -
> From: "Greg Smith" 
> To: pgsql-general@postgresql.org
> Sent: Friday, 22 April, 2011 12:49:28 AM
> Subject: Re: [GENERAL] SSDs with Postgresql?
> On 04/20/2011 01:50 AM, Toby Corkindale wrote:
> > Also, the number of erase cycles you can get, over the whole disk,
> > is
> > quite large on modern disks!
> >
> > So large that you'll probably go decades before you wear the disk
> > out,
> > even with continual writes.
> >
> > Don't buy into the SSD FUD myths..
> 
> There is no FUD being spread here. Particularly given the PostgreSQL
> WAL write pattern, it's not impossible to wear out a SSD placed there
> in
> a small number of years. A system with a trivial but not completely
> idle workload will generate one 16MB WAL segment every 5 minutes,
> which
> works out to 4.5GB/day of writes. That's the baseline--the reality is
> much, much higher than that on most systems. The fact that every row
> update can temporarily use more than 8K means that actual write
> throughput on the WAL can be shockingly large. The smallest customer I
> work with regularly has a 50GB database, yet they write 20GB of WAL
> every day. You can imagine how much WAL is generated daily on systems
> with terabyte databases.

The larger the database, the larger number of disks the DB will be spread over, 
thus keeping the amount of data written per-disk to a manageable amount. (Also, 
larger SSDs seem to have higher write-limits too)

I see Intel is/was claiming their SLC SSDs had a *minimum* lifetime of 2PB in 
writes for their 64GB disks; for your customer with a 50GB db and 20GB/day of 
WAL, that would work out at a minimum lifetime of a million days, or about 273 
years!
The cheaper "consumer grade" MLC drives should still last minimum 5 years at 
20GB/day according to their literature. (And what I found was fairly out of 
date)
That doesn't seem too bad to me - I don't think I've worked anywhere that keeps 
their traditional spinning disks in service beyond 5 years either.

> As for what this translates into in the real world, go read
> http://archives.postgresql.org/message-id/BANLkTi=GsyBfq+ApWPR_qCA7AN+NqT=z...@mail.gmail.com
> as one worked out sample. Anyone deploying PostgreSQL onto MLC can't
> necessarily ignore this issue.

Agreed, it shouldn't be ignored, but it seems like you have to have an 
early-generation SSD and combine that with very heavy write loads in order to 
risk wearing them out within a matter of years - and there are SMART attributes 
that should be able to indicate when the drive has used a lot of its life-span 
as an early-warning signal.
You've linked to one anecdotal failure, but surely there are many more people 
using SSDs successfully, who just haven't posted about it because it's working 
fine..?

-Toby

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 10 missing features

[Merlin Moncure]

On Mon, Apr 25, 2011 at 3:41 AM, Linos  wrote:
> Hi all,
>        only want to link this blog post
> http://blog.kimiensoftware.com/2011/04/top-10-missing-postgresql-features ,
> i think he may have any good points.

my take:

1. Query progress
Seen a couple of near miss proposals -- good feature, will probably
see eventually

2. Index Only Scans
visibility map could support some flavor of this in the future.  it
remains to be seen if it will actually help...

3. Session Wait Data
sounds very nice.  seems complex to implement and has some overlap
with external tools

4. Session Tracing
ditto the above.  pgfouine is pretty good and already does this

5. Multiple Block I/O
"All disk I/O goes through the OS and reads a single block at a time."
incorrect.  the o/s can read more blocks if it feels it should --
also, there are some facilities for async i/o.  I'm skeptical there is
much benefit going further here for postgres -- the storage scene is
changing fast.

6. Tablespace Quotas
Trivially done with tablespaces, although a built in solution would be
nice and probably not too tough.

7. No Logging
Beyond what's already be done and maybe a couple of corner cases, I
don't think there's much more to be done here.  There was a pretty
serious proposal for unlogged tables a while back -- I wasn't a big
fan...better to work around the facilities we have than complicate WAL
and recovery.

8. Better Export/Import Tools
I think the SQL underpinnings to pg_dump should be server side.  That
would fix a lot of the issues listed. Some of the stuff asked for we
already have but could be improved (I like dump/restore progress
idea).

9. Query Hints
I am in anti-hint camp.  I grew up without them, so learned to operate
in a different way.  Per recent discussion it's probably better to
inject assumptions into the statistics environment.

10. More Backup/Restore Options
I think the current solutions are pretty good. HS/SR, pitr, etc etc.
It's possible to rig rsync style dumps as well if you're clever.

merlin

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 10 missing features

[Nicholson, Brad (Toronto, ON, CA)]

> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Radoslaw Smogura
> Sent: Tuesday, April 26, 2011 9:55 AM
> To: Leif Biberg Kristensen
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] 10 missing features
> 
> 
>  For example, having knowledge when particular query stuck may be great
>  advantage for administrators and developers as well. Ofcourse each
>  functionality gives some overhead, but from other hand, if you create
>  important systems (like financials) "stability" and how it's easy to
>  track errors is required.


For those types of systems - lack of a true audit log is probably a bigger 
barrier.  The biggest "missing feature" are going to depend on your problem 
space.

>  Form this what I was interested and saw:
>  * I think he good pointed that logging indices, may be unneeded, as
>  those can be recreated.

Whether this is acceptable depends on your system.  Yes they can be recreated 
with a number of caveats

-performance for many systems will be poor until some (or all) indexes are 
back.  If you have SLA's based around performance you can extend your outage 
until the indexes get rebuilt.
-Indexes are used to enforce primary keys.  Are you comfortable running 
temporarily without your primary keys?
-Some replication engines rely on primary keys or unique indexes.  Losing these 
could break replication for you.

I think if you could control this on a per-index basis though it could be a win.

Brad

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 10 missing features

[Radosław Smogura]

On Tue, 26 Apr 2011 14:30:19 +0200, Leif Biberg Kristensen wrote:

On Monday 25 April 2011 10:41:36 Linos wrote:

Hi all,
only want to link this blog post

http://blog.kimiensoftware.com/2011/04/top-10-missing-postgresql-features 
,

i think he may have any good points.


Miguel Angel.


Maybe the best point is the one between the lines: That PostgreSQL is 
being
compared to Oracle on a feature-by-feature basis. I don't know if his 
views

are representative for Oracle DBAs, but it's an indication of
PostgreSQL being
considered in the same league as Oracle.

The «features» perceived to be missing from PostgreSQL by the Oracle 
DBA is

the icing on the cake. The cake itself (in terms of data integrity,
performance, scalability) is obviously regarded as totally edible.

regards, Leif


All this small features creates good database in terms of database 
system, which is administrative and developer friendly.


For example, having knowledge when particular query stuck may be great 
advantage for administrators and developers as well. Ofcourse each 
functionality gives some overhead, but from other hand, if you create 
important systems (like financials) "stability" and how it's easy to 
track errors is required.


Form this what I was interested and saw:
* I think he good pointed that logging indices, may be unneeded, as 
those can be recreated.
* Approach for I/O - I have constant feeling that ShMem is wasted for 
storing copy of system cache, but I don't know better solution, as well 
I saw in bufmgr.c method for preloading data, but I don't know if it's 
used somewhere.

* Some operations may fill cache with "trash".

Regards,
Radek

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Help - corruption issue?

[Phoenix Kiula]

On Tue, Apr 26, 2011 at 3:24 PM, Scott Marlowe  wrote:
> On Mon, Apr 25, 2011 at 8:50 PM, Phoenix Kiula  
> wrote:
>>> On Tuesday, April 26, 2011, Tomas Vondra  wrote:
 Dne 25.4.2011 18:16, Phoenix Kiula napsal(a):
> Sorry, spoke too soon.
>
> I can COPY individual chunks to files. Did that by year, and at least
> the dumping worked.
>
> Now I need to pull the data in at the destination server.
>
> If I COPY each individual file back into the table, it works. Slowly,
> but seems to work. I tried to combine all the files into one go, then
> truncate the table, and pull it all in in one go (130 million rows or
> so) but this time it gave the same error. However, it pointed out a
> specific row where the problem was:
>
> COPY links, line 15272357:
> "16426447     9s2q7   9s2q7   N       
> http://www.amazon.com/gp/search?camp=1789&creative=9325&ie=UTF8&i...";
> server closed the connection unexpectedly
>       This probably means the server terminated abnormally
>       before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
>
> Is this any use at all?  Would appreciate any pointers!

 So the dump worked fina and it fails when loading it back into the DB?
 Have you checked the output file (just see the tail). Can you post the
 part that causes issues? Just the line 16426447 and few lines around.

 regards
 Tomas
>>
>> From the old server:
>> Yearly COPY files worked. Pg_dumpall was giving problems.
>>
>> In the new server:
>> COPY FROM worked. All files appear to have been copied. Then I create
>> the primary key index, and another index. Many records are there, but
>> many are not there! There's no error, just that some records/rows just
>> didn't make it.
>
> Are you sure you're getting all the data out of the source (broken)
> database you think you are?  Are you sure those rows are in the dump?



Actually I am not. Some rows are missing.

Will a COUNT(*) on the two databases -- old and new -- be sufficient
and reliable information about the number of rows that went AWOL?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Help - corruption issue?

[Scott Marlowe]

On Mon, Apr 25, 2011 at 8:50 PM, Phoenix Kiula  wrote:
>> On Tuesday, April 26, 2011, Tomas Vondra  wrote:
>>> Dne 25.4.2011 18:16, Phoenix Kiula napsal(a):
 Sorry, spoke too soon.

 I can COPY individual chunks to files. Did that by year, and at least
 the dumping worked.

 Now I need to pull the data in at the destination server.

 If I COPY each individual file back into the table, it works. Slowly,
 but seems to work. I tried to combine all the files into one go, then
 truncate the table, and pull it all in in one go (130 million rows or
 so) but this time it gave the same error. However, it pointed out a
 specific row where the problem was:

 COPY links, line 15272357:
 "16426447     9s2q7   9s2q7   N       
 http://www.amazon.com/gp/search?camp=1789&creative=9325&ie=UTF8&i...";
 server closed the connection unexpectedly
       This probably means the server terminated abnormally
       before or while processing the request.
 The connection to the server was lost. Attempting reset: Failed.

 Is this any use at all?  Would appreciate any pointers!
>>>
>>> So the dump worked fina and it fails when loading it back into the DB?
>>> Have you checked the output file (just see the tail). Can you post the
>>> part that causes issues? Just the line 16426447 and few lines around.
>>>
>>> regards
>>> Tomas
>
> From the old server:
> Yearly COPY files worked. Pg_dumpall was giving problems.
>
> In the new server:
> COPY FROM worked. All files appear to have been copied. Then I create
> the primary key index, and another index. Many records are there, but
> many are not there! There's no error, just that some records/rows just
> didn't make it.

Are you sure you're getting all the data out of the source (broken)
database you think you are?  Are you sure those rows are in the dump?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 10 missing features

[Leif Biberg Kristensen]

On Monday 25 April 2011 10:41:36 Linos wrote:
> Hi all,
>   only want to link this blog post
> http://blog.kimiensoftware.com/2011/04/top-10-missing-postgresql-features ,
> i think he may have any good points.
> 
> 
> Miguel Angel.

Maybe the best point is the one between the lines: That PostgreSQL is being 
compared to Oracle on a feature-by-feature basis. I don't know if his views 
are representative for Oracle DBAs, but it's an indication of PostgreSQL being 
considered in the same league as Oracle.

The «features» perceived to be missing from PostgreSQL by the Oracle DBA is 
the icing on the cake. The cake itself (in terms of data integrity, 
performance, scalability) is obviously regarded as totally edible.

regards, Leif

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Partitioning an existing table

[Greg Smith]

On 04/25/2011 10:10 AM, Vick Khera wrote:
Basically, you create your partitions and set up the necessary 
triggers you want (I re-write the app to insert directly into the 
correct partition).  Then all new data starts going into the 
partitions.  Next, write a program that loops over the current master 
table, and moves the data into each partition some small hunk at a 
time, in a transaction.  This can take a long time.  For us, it took 
about 7 days to move O(100m) rows.  Then, when you're done, truncate 
the master table, and enforce that no new data is allowed to be 
inserted into it.


Vick's presentation at 
http://cdn.mailermailer.com/documents/PGCon2008TablePartitioningCaseStudy.pdf 
is still one of the best case studies of how to do this sort of 
migration around.  I was inspired by several of the ideas there when 
doing the partitioning chapter of my book, which is the only place I'm 
aware of covering this in even more detail than his case study.


Cedric's idea for how to do this even more aggressively (multiple 
workers) is what you want if this is a one-time operation you're taking 
the system down for.  In other situations, the gradual migration 
strategy Vick is suggesting is more appropriate.


Some of the other ideas suggested in this thread won't work at all, so 
be careful who you listen to here.  You can't leave copies of the data 
in the parent and put it into the child partition without all sorts of 
potential downsides.  And you really, really want to do this as a proper 
database transaction, which is easiest to express using INSERT instead 
of COPY.  If any step of the migration goes wrong, being able to do 
ROLLBACK and undo the recent bad steps is vital.


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 10 missing features

[Andrew Sullivan]

On Tue, Apr 26, 2011 at 06:21:21AM -0400, Greg Smith wrote:

> addressed doesn't start with "how can PostgreSQL duplicate the
> Oracle solution to this problem", which is how many of these
> incoming requests for features start.  The alternate question of
> "how do you provide something with the same feature set for
> PostgreSQL?" is the more useful one, and it doesn't lead to the same
> solutions.  That disconnect is important to address.

But the problem there is a really fundamental one, in that it goes to
the core of how free software gets developed: someone has a problem
that s/he wants fixed.

"The problem" in many of these cases is really, "I know how to do _x_.
How do I do that in Postgres?"  If the answer is, "You don't," it
sounds like a missing feature.

In commercial development, this is where product development managers
live.  They identify the meaning of the feature request, and then
identify how the actual need (rather than the requested feature) can
be addressed.[1] But in the free software world, of course, that won't
work unless you also have the developer hours to contribute to make
the feature.  Moreover, there is a strong preference toward 80/20
answers, because the code will have to be maintained and unless
someone who is pushing for a feature has a record of hanging around to
maintain it, there's good reason to wonder whether the feature will be
supported.  

The Postgres community is much better than most at this sort of thing,
of course, but it's hard to compete with commercial development on
refining user experience.

[1] Um, ok, the good ones do this.  The bad ones say, "Oh, people want
an animated paper clip," or, "Oh, people want us to extend PDF so that
it's an excellent vector for viruses," or, "Oh, people want high
uptime, so we'll make this multi-node failover thing that blows away
your system if you sneeze wrong," or something like that.

A

-- 
Andrew Sullivan
a...@crankycanuck.ca

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Partitioning an existing table

[Raghavendra]

>
> so now when your running application goes to query the table, it gets
> doubles?  if you do it in transactions, then how long are you going to cause
> the master table to be locked when doing such a bulk delete?
>
> my point is to minimize service interruption, and that means moving small
> hunks at a time to minimize the locks needed.
>
>
Agreed, if you are pointing to the application..

The partitioning documentation in PG is very clear on how to partition
> a new table. Create child tables, and have triggers that manage
> INSERT, UPDATE and DELETE commands.
> How about doing this with existing massive tables? (Over 120 million rows)
> I could create a new parent table with child tables, and then INSERT
> all these millions of rows to put them into the right partition. But
> is that recommended?


Here, I would go with COPY command rather than INSERT. Firstly, setup the
partition/child tables with relevant triggers and calling function on it.
Use COPY FROM command pointing to parent table by calling the .csv
file(created on MASSIVE table).  Triggers will push the data to the
respective child tables. Faster and efficient way.

Best Regards,
Raghavendra
EnterpriseDB Corporation
The Enterprise Postgres Company
Email: raghavendra@enterprisedb.com
Blog: http://raghavt.blogspot.com/

Re: [GENERAL] 10 missing features

[Greg Smith]

On 04/25/2011 04:54 PM, Nicholson, Brad (Toronto, ON, CA) wrote:
The problem is that there is a lot of noise in the add-on space. There 
are lots of things out there that are no longer supported or partially 
supported. There is a fairly high barrier of entry into figuring out 
which tools to use, how to put them together and what you can and 
can't do with them.




Right.  This is why I advise people to start on it as soon as possible, 
to make it part of the initial testing of PostgreSQL.  You have to start 
early on figuring which of the additional packages make sense for you, 
because in some environments you can't easily introduce them later if 
they weren't part of earlier QA.  I tried to work on the barrier to 
entry part in my book, there's a lot of specific recommendations for 
add-ons in there and context about what they are and aren't good for.



If (and I stress the word if) the target is winning over DBA's from the 
commercial crowd this is an important point, as those DBA's are going to be 
used to getting most of what they need in one package along with the DB.
   


Unfortunately that whole line of thinking is fundamentally incompatible 
with how open source databases are built and packaged.  What some people 
don't seem to get is that the "one package" here is "one operating 
system distribution with a good package manager".  It's not like you 
have to build all this stuff from source or anything; in many cases the 
packages are available to add with a quick search and a few clicks.



I do think the areas that are lacking in PG though do come to finer grain 
profiling of tasks.  The ability to isolate CPU and IO utilization of 
particular queries or sets of queries is something I find very useful in the 
commercial DB space that I'd love to see in Postgres.  Same goes for 
troubleshooting locking conflicts if you aren't looking at the system when they 
are happening, and tracing the causes of those locks down to finer grained 
details (IE - am I waiting on buffer eviction or xlog writes).
   


This is all true.  Unfortunately the way I expect this areas to be 
addressed doesn't start with "how can PostgreSQL duplicate the Oracle 
solution to this problem", which is how many of these incoming requests 
for features start.  The alternate question of "how do you provide 
something with the same feature set for PostgreSQL?" is the more useful 
one, and it doesn't lead to the same solutions.  That disconnect is 
important to address.  If people are only willing to work toward or fund 
solving a familiar problem, they may not recognize an alternate solution 
that is just as useful--just not as familiar--that is available or being 
built.


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general