pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedplanner, *_collapse_limit
2012-07-26 14:42 UTC Marcus Engene <mengpg2@engene.se>
` Re: planner, *_collapse_limit
2012-07-26 17:01 UTC Merlin Moncure <mmoncure@gmail.com>
[2+ messages in thread]
Geoserver-PostGIS performance problems
2012-07-24 07:21 UTC Riaan van den Dool <rvddool@csir.co.za>
` Re: Geoserver-PostGIS performance problems
2012-07-24 07:54 UTC Brett Walker <brett.walker@geometryit.com>
` Re: Geoserver-PostGIS performance problems
2012-07-24 08:10 UTC Riaan van den Dool <rvddool@csir.co.za>
` Re: Geoserver-PostGIS performance problems
2012-07-24 15:50 UTC Maciek Sakrejda <m.sakrejda@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-25 18:45 UTC Merlin Moncure <mmoncure@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-25 19:17 UTC Vinicius Abrahao <vinnix.bsd@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-25 19:26 UTC Merlin Moncure <mmoncure@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-25 19:59 UTC Vinicius Abrahao <vinnix.bsd@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-25 20:04 UTC Merlin Moncure <mmoncure@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-26 02:13 UTC Rural Hunter <ruralhunter@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-26 06:34 UTC Maciek Sakrejda <m.sakrejda@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-26 06:51 UTC Maciek Sakrejda <m.sakrejda@gmail.com>
` Re: Geoserver-PostGIS performance problems
2012-07-26 13:32 UTC Merlin Moncure <mmoncure@gmail.com>
[13+ messages in thread]
odd planner again, pg 9.0.8
2012-07-25 15:36 UTC Marcus Engene <mengpg2@engene.se>
` Re: odd planner again, pg 9.0.8
2012-07-25 16:19 UTC Pavel Stehule <pavel.stehule@gmail.com>
` Re: odd planner again, pg 9.0.8
2012-07-25 16:39 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: odd planner again, pg 9.0.8
2012-07-25 18:11 UTC Marcus Engene <mengpg2@engene.se>
[4+ messages in thread]
transactions start time
2012-07-24 11:14 UTC Aleksei Arefjev <aleksei.arefjev@nordicgaming.com>
` Re: transactions start time
2012-07-24 17:21 UTC Richard Huxton <dev@archonet.com>
` Re: transactions start time
2012-07-25 06:52 UTC Aleksei Arefjev <aleksei.arefjev@nordicgaming.com>
` Re: transactions start time
2012-07-25 07:37 UTC Aleksei Arefjev <aleksei.arefjev@nordicgaming.com>
` Re: transactions start time
2012-07-25 14:56 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: transactions start time
2012-07-25 17:01 UTC Andres Freund <andres@2ndquadrant.com>
[6+ messages in thread]
Why do I need more time with partition table?
2012-07-24 10:42 UTC AI Rumman <rummandba@gmail.com>
` Re: Why do I need more time with partition table?
2012-07-24 11:35 UTC AI Rumman <rummandba@gmail.com>
` Re: Why do I need more time with partition table?
2012-07-24 11:46 UTC Jan Otto <asche@me.com>
` Re: Why do I need more time with partition table?
2012-07-25 08:40 UTC AI Rumman <rummandba@gmail.com>
` Re: Why do I need more time with partition table?
2012-07-25 14:42 UTC Jan Otto <asche@me.com>
` Re: Why do I need more time with partition table?
2012-07-25 14:55 UTC Jeff Janes <jeff.janes@gmail.com>
[6+ messages in thread]
Heavy inserts load wile querying...
2012-07-24 13:22 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: Heavy inserts load wile querying...
2012-07-24 14:30 UTC Craig James <cjames@emolecules.com>
` Re: Heavy inserts load wile querying...
2012-07-24 14:42 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
[3+ messages in thread]
Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-17 22:56 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-17 23:48 UTC Peter Geoghegan <peter@2ndquadrant.com>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 00:13 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 00:31 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 04:00 UTC Greg Smith <greg@2ndQuadrant.com>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 04:20 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 04:57 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 05:56 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 06:00 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 07:30 UTC Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 12:26 UTC Robert Haas <robertmhaas@gmail.com>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-18 21:45 UTC Simon Riggs <simon@2ndQuadrant.com>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 04:37 UTC David Fetter <david@fetter.org>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 12:29 UTC Andrew Dunstan <andrew@dunslane.net>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 12:41 UTC David Fetter <david@fetter.org>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 12:56 UTC Andrew Dunstan <andrew@dunslane.net>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 13:04 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 13:47 UTC Andrew Dunstan <andrew@dunslane.net>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 13:58 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-23 15:02 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
2012-07-24 13:33 UTC Greg Stark <stark@mit.edu>
[21+ messages in thread]
Shards + hash = forever running queries
2012-07-23 10:03 UTC Daniele Varrazzo <daniele.varrazzo@gmail.com>
` Re: Shards + hash = forever running queries
2012-07-23 11:43 UTC Daniele Varrazzo <daniele.varrazzo@gmail.com>
` Re: Shards + hash = forever running queries
2012-07-23 15:07 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Shards + hash = forever running queries
2012-07-24 09:06 UTC Daniele Varrazzo <daniele.varrazzo@gmail.com>
[4+ messages in thread]
Efficiency of EXISTS?
2012-07-23 21:12 UTC Kenneth Tilton <ktilton@mcna.net>
` Re: Efficiency of EXISTS?
2012-07-23 21:52 UTC Merlin Moncure <mmoncure@gmail.com>
` Re: Efficiency of EXISTS?
2012-07-23 22:12 UTC Kenneth Tilton <ktilton@mcna.net>
[3+ messages in thread]
High CPU Usage
2012-06-14 15:15 UTC Siddharth Shah <siddharth.shah@elitecore.com>
` Re: High CPU Usage
2012-07-23 19:38 UTC Robert Haas <robertmhaas@gmail.com>
[2+ messages in thread]
postgres clustering interactions with pg_dump
2012-06-11 13:55 UTC Fitch, Britt <brittf@telenav.com>
` Re: postgres clustering interactions with pg_dump
2012-07-23 19:07 UTC Robert Haas <robertmhaas@gmail.com>
[2+ messages in thread]
A very long running query....
2012-07-20 21:19 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-20 21:23 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: A very long running query....
2012-07-20 21:27 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-20 21:33 UTC Rosser Schwarz <rosser.schwarz@gmail.com>
` Re: A very long running query....
2012-07-20 21:33 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: A very long running query....
2012-07-20 21:52 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-20 21:53 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-20 22:19 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-20 23:10 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: A very long running query....
2012-07-20 23:56 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-21 08:02 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: A very long running query....
2012-07-21 09:16 UTC Marc Mamin <M.Mamin@intershop.de>
` Re: A very long running query....
2012-07-21 09:22 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-21 16:58 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: A very long running query....
2012-07-21 17:42 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-21 19:16 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-21 19:19 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: A very long running query....
2012-07-21 19:24 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
` Re: A very long running query....
2012-07-21 20:10 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: A very long running query....
2012-07-21 20:11 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: A very long running query....
2012-07-21 20:29 UTC Ioannis Anagnostopoulos <ioannis@anatec.com>
[21+ messages in thread]
queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-19 11:33 UTC Felix Scheicher <mandavi@web.de>
` Re: queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-19 12:38 UTC Andrew Dunstan <andrew@dunslane.net>
` Re: queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-19 15:13 UTC Felix Scheicher <mandavi@web.de>
` Re: queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-19 15:48 UTC Andrew Dunstan <andrew@dunslane.net>
` Re: queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-19 16:12 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-19 17:04 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-19 17:24 UTC mandavi <mandavi@web.de>
` Re: queries are fast after dump->restore but slow again after some days dispite vacuum
2012-07-20 07:10 UTC Laszlo Nagy <gandalf@shopzeus.com>
[8+ messages in thread]
optimizing queries using IN and EXISTS
2012-07-18 16:10 UTC Nick Hofstede <Nick.Hofstede@inventivegroup.com>
` Re: optimizing queries using IN and EXISTS
2012-07-18 18:40 UTC Peter Geoghegan <peter@2ndquadrant.com>
` Re: optimizing queries using IN and EXISTS
2012-07-18 20:28 UTC Nick Hofstede <Nick.Hofstede@inventivegroup.com>
` Re: optimizing queries using IN and EXISTS
2012-07-18 22:36 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: optimizing queries using IN and EXISTS
2012-07-19 11:53 UTC Nick Hofstede <Nick.Hofstede@inventivegroup.com>
[5+ messages in thread]
Process 11812 still waiting for ExclusiveLock on extension of relation
2012-07-17 15:57 UTC David Kerr <dmk@mr-paradox.net>
` Re: Process 11812 still waiting for ExclusiveLock on extension of relation
2012-07-18 12:08 UTC Sergey Konoplev <sergey.konoplev@postgresql-consulting.com>
` Re: Process 11812 still waiting for ExclusiveLock on extension of relation
2012-07-19 01:43 UTC David Kerr <dmk@mr-paradox.net>
[3+ messages in thread]
Sequencial scan in a JOIN
2012-06-05 12:48 UTC Andrew Jaimes <andrewjaimes@hotmail.com>
` Re: Sequencial scan in a JOIN
2012-06-05 13:15 UTC Shaun Thomas <sthomas@optionshouse.com>
` Re: Sequencial scan in a JOIN
2012-06-05 13:31 UTC Andrew Jaimes <andrewjaimes@hotmail.com>
` Re: Sequencial scan in a JOIN
2012-06-05 14:02 UTC Shaun Thomas <sthomas@optionshouse.com>
` Re: Sequencial scan in a JOIN
2012-06-05 14:57 UTC Shaun Thomas <sthomas@optionshouse.com>
` Re: Sequencial scan in a JOIN
2012-07-18 20:00 UTC Robert Haas <robertmhaas@gmail.com>
[6+ messages in thread]
Array fundamentals
2012-06-02 17:05 UTC idc danny <idcdanny@yahoo.com>
` Re: [PERFORM] Array fundamentals
2012-06-02 17:21 UTC Jeff Davis <pgsql@j-davis.com>
` Re: Array fundamentals
2012-07-18 19:32 UTC Robert Haas <robertmhaas@gmail.com>
[3+ messages in thread]
PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-03 15:22 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 11:29 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 11:35 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 11:38 UTC Daniel Farina <daniel@heroku.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 13:25 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 13:30 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 13:38 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 13:39 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 13:45 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 13:51 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 14:14 UTC Andres Freund <andres@2ndquadrant.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 14:22 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 14:46 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 15:24 UTC Marc Mamin <M.Mamin@intershop.de>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 15:27 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 15:44 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 15:57 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 16:06 UTC Steve Crawford <scrawford@pinpointresearch.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-06 18:32 UTC Chris Hanks <christopher.m.hanks@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-13 07:50 UTC Stanislaw Pankevich <s.pankevich@gmail.com>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-14 03:35 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
2012-07-18 14:33 UTC Merlin Moncure <mmoncure@gmail.com>
[22+ messages in thread]
monitoring suggestions
2012-07-18 14:27 UTC Campbell, Lance <lance@illinois.edu>
postgresql query cost values/estimates
2012-07-18 12:18 UTC John Lister <john.lister@kickstone.com>
Slow application response on lightly loaded server?
2012-07-17 16:27 UTC Mike Blackwell <mike.blackwell@rrd.com>
` Re: Slow application response on lightly loaded server?
2012-07-17 16:35 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Slow application response on lightly loaded server?
2012-07-17 17:37 UTC Mike Blackwell <mike.blackwell@rrd.com>
` Re: Slow application response on lightly loaded server?
2012-07-17 17:49 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Slow application response on lightly loaded server?
2012-07-17 18:10 UTC Mike Blackwell <mike.blackwell@rrd.com>
` Re: Slow application response on lightly loaded server?
2012-07-17 19:36 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Slow application response on lightly loaded server?
2012-07-17 19:48 UTC Mike Blackwell <mike.blackwell@rrd.com>
` Re: Slow application response on lightly loaded server?
2012-07-17 21:00 UTC Scott Marlowe <scott.marlowe@gmail.com>
[8+ messages in thread]
very very slow inserts into very large table
2012-07-16 13:37 UTC Jon Nelson <jnelson+pgsql@jamponi.net>
` Re: very very slow inserts into very large table
2012-07-16 14:06 UTC Mark Thornton <mthornton@optrak.com>
` Re: very very slow inserts into very large table
2012-07-16 17:35 UTC Samuel Gendler <sgendler@ideasculptor.com>
` Re: very very slow inserts into very large table
2012-07-16 17:56 UTC Jon Nelson <jnelson+pgsql@jamponi.net>
` Re: very very slow inserts into very large table
2012-07-16 18:28 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: very very slow inserts into very large table
2012-07-16 18:59 UTC Mark Thornton <mthornton@optrak.com>
` Re: very very slow inserts into very large table
2012-07-16 19:08 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: very very slow inserts into very large table
2012-07-16 19:16 UTC Mark Thornton <mthornton@optrak.com>
` Re: very very slow inserts into very large table
2012-07-16 20:01 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: very very slow inserts into very large table
2012-07-17 03:30 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: very very slow inserts into very large table
2012-07-17 03:49 UTC Satoshi Nagayasu <snaga@uptime.jp>
` Re: very very slow inserts into very large table
2012-07-17 15:59 UTC Ants Aasma <ants@cybertec.at>
` Re: very very slow inserts into very large table
2012-07-17 16:24 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: very very slow inserts into very large table
2012-07-17 16:55 UTC Claudio Freire <klaussfreire@gmail.com>
[14+ messages in thread]
PostgreSQL index issue
2012-07-12 00:03 UTC codevally <codevally.mail.list@gmail.com>
` Re: PostgreSQL index issue
2012-07-16 07:44 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
[2+ messages in thread]
Proposed change for 9.3(?): Require full restart to change fsync parameter, not just pg_ctl reload
2012-07-16 01:54 UTC Craig Ringer <ringerc@ringerc.id.au>
Any tool/script available which can be used to measure scalability of an application's database.
2012-07-10 08:21 UTC Sreejith Balakrishnan <sreejith.balakrishnan@tcs.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-13 18:37 UTC Sergey Konoplev <gray.ru@gmail.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-13 20:06 UTC Robert Klemme <shortcutter@googlemail.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 01:21 UTC B Sreejith <bsreejithin@gmail.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 01:26 UTC B Sreejith <bsreejithin@gmail.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 05:05 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 08:48 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 09:10 UTC John Jones <idolchatter@gmail.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 09:50 UTC B Sreejith <bsreejithin@gmail.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 12:17 UTC Robert Klemme <shortcutter@googlemail.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 12:49 UTC Sergey Konoplev <sergey.konoplev@postgresql-consulting.com>
` Re: Any tool/script available which can be used to measure scalability of an application's database.
2012-07-14 15:10 UTC Craig Ringer <ringerc@ringerc.id.au>
[12+ messages in thread]
[next (older)]
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox