pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedA 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]
Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
2012-07-13 14:11 UTC Eoghan Murray <eoghan@qatano.com>
` Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
2012-07-13 15:53 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
2012-07-13 16:40 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
2012-07-13 17:40 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
2012-07-13 18:56 UTC Claudio Freire <klaussfreire@gmail.com>
[5+ messages in thread]
Is there a tool available to perform Data Model review, from a performance perspective?
2012-07-13 16:25 UTC B Sreejith <bsreejithin@gmail.com>
slow prepare, lots of semop calls.
2012-07-13 06:51 UTC David Kerr <dmk@mr-paradox.net>
how could select id=xx so slow?
2012-07-06 06:17 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-06 09:46 UTC Daniel Farina <daniel@heroku.com>
` Re: how could select id=xx so slow?
2012-07-06 11:16 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: how could select id=xx so slow?
2012-07-06 13:10 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
` Re: how could select id=xx so slow?
2012-07-09 09:20 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-10 01:25 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: how could select id=xx so slow?
2012-07-10 02:25 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-10 02:46 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: how could select id=xx so slow?
2012-07-10 02:58 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-11 06:24 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-11 08:23 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
` Re: how could select id=xx so slow?
2012-07-11 11:40 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-11 11:59 UTC Ants Aasma <ants@cybertec.at>
` Re: how could select id=xx so slow?
2012-07-11 16:35 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-12 00:18 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: how could select id=xx so slow?
2012-07-12 00:47 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-12 01:07 UTC Maciek Sakrejda <m.sakrejda@gmail.com>
` Re: how could select id=xx so slow?
2012-07-12 02:20 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: how could select id=xx so slow?
2012-07-12 05:10 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-12 06:56 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: how could select id=xx so slow?
2012-07-12 12:48 UTC Yan Chunlu <springrider@gmail.com>
` Re: how could select id=xx so slow?
2012-07-12 14:39 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: how could select id=xx so slow?
2012-07-12 16:07 UTC Ants Aasma <ants@cybertec.at>
` Re: how could select id=xx so slow?
2012-07-12 18:53 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: how could select id=xx so slow?
2012-07-13 04:02 UTC Yan Chunlu <springrider@gmail.com>
[25+ messages in thread]
moving tables
2012-06-20 22:27 UTC Midge Brown <midgems@sbcglobal.net>
` Re: moving tables
2012-06-21 00:28 UTC Josh Berkus <josh@agliodbs.com>
` Re: moving tables
2012-06-21 08:34 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
` Re: moving tables
2012-07-11 17:25 UTC Midge Brown <midgems@sbcglobal.net>
[4+ messages in thread]
Paged Query
2012-07-04 12:25 UTC Hermann Matthes <hermann.matthes@web.de>
` Re: Paged Query
2012-07-06 13:18 UTC Віталій Тимчишин <tivv00@gmail.com>
` Re: Paged Query
2012-07-06 13:19 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
` Re: Paged Query
2012-07-06 13:35 UTC Greg Spiegelberg <gspiegelberg@gmail.com>
` Re: Paged Query
2012-07-06 13:43 UTC Misa Simic <misa.simic@gmail.com>
` Re: Paged Query
2012-07-09 11:55 UTC Gregg Jaskiewicz <gryzman@gmail.com>
` Re: Paged Query
2012-07-09 12:02 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Paged Query
2012-07-09 13:22 UTC Shaun Thomas <sthomas@optionshouse.com>
` Re: Paged Query
2012-07-09 14:16 UTC Craig James <cjames@emolecules.com>
` Re: Paged Query
2012-07-09 14:33 UTC Greg Spiegelberg <gspiegelberg@gmail.com>
` Re: Paged Query
2012-07-09 17:41 UTC Misa Simic <misa.simic@gmail.com>
` Re: Paged Query
2012-07-09 17:46 UTC Andrew Dunstan <andrew@dunslane.net>
` Re: Paged Query
2012-07-09 18:13 UTC Gurjeet Singh <singh.gurjeet@gmail.com>
` Re: Paged Query
2012-07-09 22:24 UTC Misa Simic <misa.simic@gmail.com>
` Re: Paged Query
2012-07-09 23:48 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Paged Query
2012-07-09 23:50 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Paged Query
2012-07-10 00:34 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Paged Query
2012-07-11 08:15 UTC Віталій Тимчишин <tivv00@gmail.com>
` Re: Paged Query
2012-07-11 08:23 UTC Віталій Тимчишин <tivv00@gmail.com>
[19+ messages in thread]
The need for clustered indexes to boost TPC-V performance
2012-07-03 23:13 UTC Reza Taheri <rtaheri@vmware.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-04 05:43 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-04 07:57 UTC Thomas Kellerer <spam_eater@gmx.net>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-04 08:31 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-04 13:39 UTC Daniel Farina <daniel@heroku.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-04 14:26 UTC Claudio Freire <klaussfreire@gmail.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-05 12:30 UTC Robert Klemme <shortcutter@googlemail.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-05 19:10 UTC Reza Taheri <rtaheri@vmware.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-05 19:13 UTC Reza Taheri <rtaheri@vmware.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-05 19:46 UTC Samuel Gendler <sgendler@ideasculptor.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-05 20:37 UTC Reza Taheri <rtaheri@vmware.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-05 20:52 UTC Samuel Gendler <sgendler@ideasculptor.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 00:41 UTC Andy Colson <andy@squeakycode.net>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 00:46 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 00:57 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 01:00 UTC Reza Taheri <rtaheri@vmware.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 01:04 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 01:42 UTC Greg Smith <greg@2ndQuadrant.com>
` Re: [PERFORM] The need for clustered indexes to boost TPC-V performance
2012-07-06 03:02 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 03:08 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 03:33 UTC Reza Taheri <rtaheri@vmware.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-06 04:19 UTC Reza Taheri <rtaheri@vmware.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-10 19:05 UTC Merlin Moncure <mmoncure@gmail.com>
` Re: The need for clustered indexes to boost TPC-V performance
2012-07-10 19:35 UTC Reza Taheri <rtaheri@vmware.com>
[24+ messages in thread]
Massive I/O spikes during checkpoint
2012-07-10 05:39 UTC David Kerr <dmk@mr-paradox.net>
` Re: Massive I/O spikes during checkpoint
2012-07-10 05:51 UTC Maxim Boguk <maxim.boguk@gmail.com>
` Re: Massive I/O spikes during checkpoint
2012-07-10 05:52 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Massive I/O spikes during checkpoint
2012-07-10 05:59 UTC David Kerr <dmk@mr-paradox.net>
` Re: Massive I/O spikes during checkpoint
2012-07-10 06:03 UTC David Kerr <dmk@mr-paradox.net>
` Re: Massive I/O spikes during checkpoint
2012-07-10 06:14 UTC Maxim Boguk <maxim.boguk@gmail.com>
` Re: Massive I/O spikes during checkpoint
2012-07-10 06:17 UTC David Kerr <dmk@mr-paradox.net>
` Re: Massive I/O spikes during checkpoint
2012-07-10 12:44 UTC Andres Freund <andres@2ndquadrant.com>
` Re: Massive I/O spikes during checkpoint
2012-07-10 13:36 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Massive I/O spikes during checkpoint
2012-07-10 13:41 UTC Andres Freund <andres@2ndquadrant.com>
[10+ messages in thread]
Custom function in where clause
2012-07-10 08:36 UTC Pena Kupen <kupen@wippies.fi>
` Re: Custom function in where clause
2012-07-10 08:44 UTC Maxim Boguk <maxim.boguk@gmail.com>
` Re: Custom function in where clause
2012-07-10 08:45 UTC Brendan Jurd <direvus@gmail.com>
` Re: Custom function in where clause
2012-07-10 09:30 UTC Pena Kupen <kupen@wippies.fi>
` Fw: Re: Custom function in where clause
2012-07-10 10:20 UTC Pena Kupen <kupen@wippies.fi>
[5+ messages in thread]
Create tables performance
2012-07-06 15:15 UTC Sylvain CAILLET <scaillet@alaloop.com>
` Re: Create tables performance
2012-07-06 17:22 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Create tables performance
2012-07-06 18:12 UTC Richard Huxton <dev@archonet.com>
` Re: Create tables performance
2012-07-07 02:27 UTC Craig Ringer <ringerc@ringerc.id.au>
` Re: Create tables performance
2012-07-09 06:49 UTC Sylvain CAILLET <scaillet@alaloop.com>
` Re: Create tables performance
2012-07-09 17:02 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Create tables performance
2012-07-10 06:27 UTC Sylvain CAILLET <scaillet@alaloop.com>
[7+ messages in thread]
SSDs again, LSI Warpdrive 2 anyone?
2012-07-06 00:51 UTC Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
` Re: SSDs again, LSI Warpdrive 2 anyone?
2012-07-06 04:08 UTC Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
` Re: SSDs again, LSI Warpdrive 2 anyone?
2012-07-09 17:16 UTC jamonb <jamon.bowen@lsi.com>
[3+ 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