pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedmoving pg_xlog -- yeah, it's worth it!
2010-02-09 16:14 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-09 16:22 UTC Jesper Krogh <jesper@krogh.cc>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-09 16:33 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-09 17:37 UTC Amitabh Kant <amitabhkant@gmail.com>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-09 17:44 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-11 11:29 UTC Bruce Momjian <bruce@momjian.us>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-11 16:12 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-11 17:48 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-11 17:57 UTC Alvaro Herrera <alvherre@commandprompt.com>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-11 18:04 UTC Aidan Van Dyk <aidan@highrise.ca>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-11 18:19 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-12 13:21 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-12 14:03 UTC Alvaro Herrera <alvherre@commandprompt.com>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-12 14:10 UTC Alvaro Herrera <alvherre@commandprompt.com>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-12 14:49 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-12 20:11 UTC Alvaro Herrera <alvherre@commandprompt.com>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-13 06:29 UTC Greg Smith <greg@2ndquadrant.com>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-23 21:23 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: moving pg_xlog -- yeah, it's worth it!
2010-02-23 22:14 UTC Ben Chobot <bench@silentmedia.com>
[19+ messages in thread]
Re: Slow query: table iteration (8.3)
2010-02-01 14:54 UTC Yeb Havinga <yebhavinga@gmail.com>
` Re: Slow query: table iteration (8.3)
2010-02-02 02:52 UTC Glenn Maynard <glenn@zewt.org>
` Re: Slow query: table iteration (8.3)
2010-02-02 10:06 UTC Yeb Havinga <yebhavinga@gmail.com>
` Re: Slow query: table iteration (8.3)
2010-02-04 03:05 UTC Robert Haas <robertmhaas@gmail.com>
` Re: Slow query: table iteration (8.3)
2010-02-04 06:30 UTC Glenn Maynard <glenn@zewt.org>
` Re: Slow query: table iteration (8.3)
2010-02-04 08:24 UTC Glenn Maynard <glenn@zewt.org>
` Re: Slow query: table iteration (8.3)
2010-02-04 08:28 UTC Grzegorz Jaśkiewicz <gryzman@gmail.com>
` Re: Slow query: table iteration (8.3)
2010-02-04 09:09 UTC Glenn Maynard <glenn@zewt.org>
` Re: Slow query: table iteration (8.3)
2010-02-04 21:57 UTC Robert Haas <robertmhaas@gmail.com>
` Re: Slow query: table iteration (8.3)
2010-02-05 03:04 UTC Glenn Maynard <glenn@zewt.org>
` Re: Slow query: table iteration (8.3)
2010-02-05 11:17 UTC Yeb Havinga <yebhavinga@gmail.com>
` Re: Slow query: table iteration (8.3)
2010-02-06 01:35 UTC Glenn Maynard <glenn@zewt.org>
` Re: Slow query: table iteration (8.3)
2010-02-06 06:31 UTC Robert Haas <robertmhaas@gmail.com>
` Re: Slow query: table iteration (8.3)
2010-02-23 12:18 UTC Yeb Havinga <yebhavinga@gmail.com>
[14+ messages in thread]
Advice requested on structuring aggregation queries
2010-02-23 03:01 UTC Dave Crooke <dcrooke@gmail.com>
` Re: Advice requested on structuring aggregation queries
2010-02-23 05:23 UTC Joe Conway <mail@joeconway.com>
[2+ messages in thread]
plpgsql plan cache
2010-02-22 19:26 UTC Joel Jacobson <joel@gluefinance.com>
` Re: plpgsql plan cache
2010-02-22 19:42 UTC Pierre C <lists@peufeu.com>
` Re: plpgsql plan cache
2010-02-22 19:58 UTC Joel Jacobson <joel@gluefinance.com>
` Re: plpgsql plan cache
2010-02-22 21:20 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: plpgsql plan cache
2010-02-22 21:23 UTC Nikolas Everett <nik9000@gmail.com>
` Re: plpgsql plan cache
2010-02-22 21:47 UTC Joel Jacobson <joel@gluefinance.com>
` Re: plpgsql plan cache
2010-02-22 22:15 UTC Pierre C <lists@peufeu.com>
[7+ messages in thread]
AutoVacuum_NapTime
2010-02-21 01:03 UTC George Sexton <georges@mhsoftware.com>
` Re: AutoVacuum_NapTime
2010-02-21 01:15 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: AutoVacuum_NapTime
2010-02-21 01:29 UTC George Sexton <georges@mhsoftware.com>
` Re: AutoVacuum_NapTime
2010-02-22 12:43 UTC Alvaro Herrera <alvherre@commandprompt.com>
[4+ messages in thread]
Auto Vacuum out of memory
2010-02-15 20:20 UTC Rose Zhou <rose@anatec.com>
` Re: Auto Vacuum out of memory
2010-02-21 18:44 UTC Robert Haas <robertmhaas@gmail.com>
[2+ messages in thread]
can we optimize STACK_DEPTH_SLOP
2010-02-21 02:53 UTC terry <94487509@qq.com>
` can we optimize STACK_DEPTH_SLOP
2010-02-21 03:05 UTC terry <94487509@qq.com>
` Re: can we optimize STACK_DEPTH_SLOP
2010-02-21 03:25 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: can we optimize STACK_DEPTH_SLOP
2010-02-21 05:44 UTC terry <94487509@qq.com>
[4+ messages in thread]
bgwriter tunables vs pg_stat_bgwriter
2010-02-17 13:30 UTC Jeff <threshar@torgo.978.org>
` Re: bgwriter tunables vs pg_stat_bgwriter
2010-02-17 19:01 UTC Brad Nicholson <bnichols@ca.afilias.info>
` Re: bgwriter tunables vs pg_stat_bgwriter
2010-02-17 23:23 UTC Greg Smith <greg@2ndquadrant.com>
` Re: bgwriter tunables vs pg_stat_bgwriter
2010-02-18 13:35 UTC Jeff <threshar@torgo.978.org>
[4+ messages in thread]
index usage in not like
2010-02-18 11:55 UTC AI Rumman <rummandba@gmail.com>
` Re: index usage in not like
2010-02-18 12:00 UTC Thom Brown <thombrown@gmail.com>
` Re: index usage in not like
2010-02-18 12:14 UTC Thom Brown <thombrown@gmail.com>
` Re: index usage in not like
2010-02-18 12:18 UTC A. Kretschmer <andreas.kretschmer@schollglas.com>
` Re: index usage in not like
2010-02-18 12:26 UTC Kenneth Marshall <ktm@rice.edu>
` Re: index usage in not like
2010-02-18 12:40 UTC Thom Brown <thombrown@gmail.com>
` Re: index usage in not like
2010-02-18 12:43 UTC A. Kretschmer <andreas.kretschmer@schollglas.com>
[7+ messages in thread]
Michael Clemmons wants to stay in touch on LinkedIn
2010-02-18 01:04 UTC Michael Clemmons <glassresistor@gmail.com>
disk space usage unexpected
2010-02-15 19:59 UTC Rose Zhou <rose@anatec.com>
` Re: disk space usage unexpected
2010-02-15 21:15 UTC Ben Chobot <bench@silentmedia.com>
` Re: disk space usage unexpected
2010-02-15 21:25 UTC Rose Zhou <rose@anatec.com>
` Re: disk space usage unexpected
2010-02-16 01:24 UTC Joshua D. Drake <jd@commandprompt.com>
` Re: disk space usage unexpected
2010-02-17 18:34 UTC Ben Chobot <bench@silentmedia.com>
` Re: disk space usage unexpected
2010-02-17 18:43 UTC Rose Zhou <rose@anatec.com>
[6+ messages in thread]
Dell PERC H700/H800
2010-02-11 12:39 UTC Matthew Wakeling <matthew@flymine.org>
` Re: Dell PERC H700/H800
2010-02-11 17:26 UTC Joshua D. Drake <jd@commandprompt.com>
` Re: Dell PERC H700/H800
2010-02-11 17:42 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Dell PERC H700/H800
2010-02-11 20:11 UTC James Mansion <james@mansionfamily.plus.com>
` Re: Dell PERC H700/H800
2010-02-11 20:58 UTC Łukasz Jagiełło <lukasz.jagiello@gforces.pl>
` Re: Dell PERC H700/H800
2010-02-11 21:55 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Dell PERC H700/H800
2010-02-12 19:03 UTC Dave Crooke <dcrooke@gmail.com>
` Re: Dell PERC H700/H800
2010-02-13 07:05 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Dell PERC H700/H800
2010-02-13 08:31 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Dell PERC H700/H800
2010-02-16 14:12 UTC Bruce Momjian <bruce@momjian.us>
` Re: Dell PERC H700/H800
2010-02-17 13:07 UTC Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
[11+ messages in thread]
8.1 -> 8.4 regression
2010-02-14 18:38 UTC Ben Chobot <bench@silentmedia.com>
` Re: 8.1 -> 8.4 regression
2010-02-15 09:40 UTC Dennis Björklund <db@zigo.dhs.org>
` Re: 8.1 -> 8.4 regression
2010-02-15 15:59 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: 8.1 -> 8.4 regression
2010-02-15 16:16 UTC Ben Chobot <bench@silentmedia.com>
` Re: 8.1 -> 8.4 regression
2010-02-15 17:26 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: 8.1 -> 8.4 regression
2010-02-15 17:35 UTC Ben Chobot <bench@silentmedia.com>
` Re: 8.1 -> 8.4 regression
2010-02-17 05:34 UTC Tom Lane <tgl@sss.pgh.pa.us>
[7+ messages in thread]
another 8.1->8.4 regression
2010-02-16 21:29 UTC Ben Chobot <bench@silentmedia.com>
` Re: another 8.1->8.4 regression
2010-02-16 23:39 UTC Ben Chobot <bench@silentmedia.com>
[2+ messages in thread]
Linux I/O tuning: CFQ vs. deadline
2010-02-08 09:45 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-08 14:57 UTC Albe Laurenz <laurenz.albe@wien.gv.at>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-08 15:24 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-08 15:30 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-08 17:49 UTC Josh Berkus <josh@agliodbs.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-08 18:59 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-09 01:14 UTC Mark Wong <markwkm@gmail.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-09 03:50 UTC Scott Carey <scott@richrelevance.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-09 04:14 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-09 04:16 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-09 04:35 UTC david@lang.hm
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-09 19:14 UTC Jeff <threshar@torgo.978.org>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-10 06:37 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-10 07:11 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-10 17:22 UTC Jeff <threshar@torgo.978.org>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-10 18:04 UTC Scott Carey <scott@richrelevance.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-11 01:46 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-11 01:52 UTC david@lang.hm
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-11 02:09 UTC Greg Smith <greg@2ndquadrant.com>
` Re: Linux I/O tuning: CFQ vs. deadline
2010-02-16 21:34 UTC Jeff Davis <pgsql@j-davis.com>
[20+ messages in thread]
Almost infinite query -> Different Query Plan when changing where clause value
2010-02-12 13:35 UTC lionel duboeuf <lionel.duboeuf@boozter.com>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-12 15:05 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-12 20:32 UTC lionel duboeuf <lionel.duboeuf@boozter.com>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-12 20:59 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-15 09:52 UTC lionel duboeuf <lionel.duboeuf@boozter.com>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-15 14:19 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-15 17:24 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-16 10:26 UTC lionel duboeuf <lionel.duboeuf@boozter.com>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-16 10:26 UTC lionel duboeuf <lionel.duboeuf@boozter.com>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-16 12:45 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-16 16:39 UTC lionel duboeuf <lionel.duboeuf@boozter.com>
` Re: Almost infinite query -> Different Query Plan when changing where clause value
2010-02-16 16:47 UTC lionel duboeuf <lionel.duboeuf@boozter.com>
[12+ messages in thread]
Why index is not using here?
2010-02-16 11:43 UTC AI Rumman <rummandba@gmail.com>
` Re: Why index is not using here?
2010-02-16 11:44 UTC AI Rumman <rummandba@gmail.com>
` Re: Why index is not using here?
2010-02-16 14:56 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
[3+ messages in thread]
512, 600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-10 04:04 UTC Bryce Nesbitt <bryce2@obviously.com>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-10 08:29 UTC Bryce Nesbitt <bryce2@obviously.com>
` Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-10 09:11 UTC Pavel Stehule <pavel.stehule@gmail.com>
` Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-10 20:31 UTC Robert Haas <robertmhaas@gmail.com>
` Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-10 23:18 UTC Jorge Montero <jorge_montero@homedecorators.com>
` Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-11 01:52 UTC Bryce Nesbitt <bryce2@obviously.com>
` Re: Re: 512, 600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-11 03:52 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-11 13:29 UTC Robert Haas <robertmhaas@gmail.com>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-12 15:09 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-12 16:05 UTC Karl Denninger <karl@denninger.net>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-12 16:11 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-12 16:43 UTC Karl Denninger <karl@denninger.net>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-12 16:54 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
` Re: 512, 600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-12 20:07 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-13 07:45 UTC Bryce Nesbitt <bryce2@obviously.com>
` Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-13 07:55 UTC Bryce Nesbitt <bryce2@obviously.com>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-13 07:58 UTC Bryce Nesbitt <bryce2@obviously.com>
` Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-13 08:09 UTC Bryce Nesbitt <bryce2@obviously.com>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-13 15:40 UTC Pierre Frédéric Caillaud <lists@peufeu.com>
` Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
2010-02-15 16:41 UTC Robert Haas <robertmhaas@gmail.com>
[20+ messages in thread]
Why primary key index are not using in joining?
2010-02-15 09:35 UTC AI Rumman <rummandba@gmail.com>
` Re: Why primary key index are not using in joining?
2010-02-15 09:50 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: Why primary key index are not using in joining?
2010-02-15 11:11 UTC Yeb Havinga <yebhavinga@gmail.com>
` Re: Why primary key index are not using in joining?
2010-02-15 15:32 UTC Tom Lane <tgl@sss.pgh.pa.us>
[4+ messages in thread]
PostgreSQL on SMP Architectures
2010-02-14 16:36 UTC Reydan Cankur <reydan.cankur@gmail.com>
` Re: PostgreSQL on SMP Architectures
2010-02-14 17:12 UTC Arjen van der Meijden <acmmailing@tweakers.net>
` Re: PostgreSQL on SMP Architectures
2010-02-14 18:25 UTC Scott Marlowe <scott.marlowe@gmail.com>
` Re: PostgreSQL on SMP Architectures
2010-02-14 18:46 UTC Reydan Cankur <reydan.cankur@gmail.com>
` Re: PostgreSQL on SMP Architectures
2010-02-14 19:05 UTC Boszormenyi Zoltan <zb@cybertec.at>
` Re: PostgreSQL on SMP Architectures
2010-02-15 14:33 UTC Kevin Grittner <Kevin.Grittner@wicourts.gov>
[6+ messages in thread]
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 17:36 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 17:43 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 17:50 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 18:14 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 18:34 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 19:06 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 19:08 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 19:33 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-02 19:45 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-03 11:53 UTC Greg Stark <gsstark@mit.edu>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-03 12:03 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-03 13:42 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-03 14:19 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-06 05:03 UTC Greg Smith <greg@2ndquadrant.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-06 12:03 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-07 05:13 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-07 09:23 UTC Greg Smith <greg@2ndquadrant.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-07 16:24 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-07 18:23 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-07 18:27 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-08 01:31 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-08 03:09 UTC Alvaro Herrera <alvherre@commandprompt.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-08 04:53 UTC Robert Haas <robertmhaas@gmail.com>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-08 07:13 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-08 18:34 UTC Greg Stark <gsstark@mit.edu>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-08 19:29 UTC Andres Freund <andres@anarazel.de>
` Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-11 02:27 UTC Andres Freund <andres@anarazel.de>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-12 15:49 UTC Robert Haas <robertmhaas@gmail.com>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 14:03 UTC Greg Stark <gsstark@mit.edu>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 15:31 UTC Greg Stark <gsstark@mit.edu>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 17:11 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 17:27 UTC Andres Freund <andres@anarazel.de>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 17:37 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Re: Faster CREATE DATABASE by delaying fsync
2010-02-14 20:24 UTC Florian Weimer <fw@deneb.enyo.de>
` Re: Re: Faster CREATE DATABASE by delaying fsync
2010-02-14 20:41 UTC Mark Mielke <mark@mark.mielke.cc>
` Re: Re: Faster CREATE DATABASE by delaying fsync
2010-02-14 20:49 UTC Andres Freund <andres@anarazel.de>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 20:57 UTC Robert Haas <robertmhaas@gmail.com>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 21:43 UTC Andres Freund <andres@anarazel.de>
` Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
2010-02-14 23:33 UTC Greg Stark <gsstark@mit.edu>
` Re: Re: Faster CREATE DATABASE by delaying fsync
2010-02-15 00:08 UTC Mark Mielke <mark@mark.mielke.cc>
[40+ messages in thread]
Deferred constraint and delete performance
2010-02-10 10:55 UTC Franck Routier <franck.routier@axege.com>
` Re: Deferred constraint and delete performance
2010-02-10 14:56 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Deferred constraint and delete performance
2010-02-10 17:36 UTC Andres Freund <andres@anarazel.de>
` Re: Deferred constraint and delete performance
2010-02-14 09:45 UTC Віталій Тимчишин <tivv00@gmail.com>
[4+ messages in thread]
Questions on plan with INSERT/SELECT on partitioned table
2010-02-12 16:03 UTC Connors, Bill <BConnors@rochgrp.com>
` Re: Questions on plan with INSERT/SELECT on partitioned table
2010-02-12 18:20 UTC Tom Lane <tgl@sss.pgh.pa.us>
[2+ messages in thread]
Immutable table functions
2010-02-12 12:54 UTC Luiz Angelo Daros de Luca <luizluca@gmail.com>
` Re: Immutable table functions
2010-02-12 13:31 UTC Yeb Havinga <yebhavinga@gmail.com>
[2+ messages in thread]
perf problem with huge table
2010-02-10 22:13 UTC rama <rama.rama@tiscali.it>
` Re: perf problem with huge table
2010-02-10 22:45 UTC Justin Graf <justin@magwerks.com>
` Re: perf problem with huge table
2010-02-10 23:16 UTC Dave Crooke <dcrooke@gmail.com>
` Re: perf problem with huge table
2010-02-10 23:30 UTC Jon Lewison <jlewison1@gmail.com>
` Re: perf problem with huge table
2010-02-10 23:48 UTC Dave Crooke <dcrooke@gmail.com>
` Re: perf problem with huge table
2010-02-11 00:09 UTC Jon Lewison <jlewison1@gmail.com>
` Re: perf problem with huge table
2010-02-11 00:51 UTC Dave Crooke <dcrooke@gmail.com>
` Re: perf problem with huge table
2010-02-11 01:42 UTC Greg Smith <greg@2ndquadrant.com>
` Re: perf problem with huge table
2010-02-11 10:05 UTC jesper@krogh.cc
` Re: perf problem with huge table
2010-02-11 14:39 UTC Leo Mannhart <leo.mannhart@beecom.ch>
[10+ 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