pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPostgreSQL 11 higher Planning time on Partitioned table
2020-02-23 09:56 UTC Ravi Garg <ravi.garg@yahoo.com>
` Re: PostgreSQL 11 higher Planning time on Partitioned table
2020-02-23 10:12 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: PostgreSQL 11 higher Planning time on Partitioned table
2020-02-23 10:46 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: PostgreSQL 11 higher Planning time on Partitioned table
2020-02-23 10:57 UTC Ravi Garg <ravi.garg@yahoo.com>
` Re: PostgreSQL 11 higher Planning time on Partitioned table
2020-02-23 15:10 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: PostgreSQL 11 higher Planning time on Partitioned table
2020-02-23 16:18 UTC Imre Samu <pella.samu@gmail.com>
` Re: PostgreSQL 11 higher Planning time on Partitioned table
2020-02-24 19:40 UTC Ravi Garg <ravi.garg@yahoo.com>
` Re: PostgreSQL 11 higher Planning time on Partitioned table
2020-02-24 19:44 UTC Ravi Garg <ravi.garg@yahoo.com>
[8+ messages in thread]
DB running out of memory issues after upgrade
2020-02-18 17:46 UTC Nagaraj Raj <nagaraj.sf@yahoo.com>
` Re: DB running out of memory issues after upgrade
2020-02-18 17:58 UTC Tomas Vondra <tomas.vondra@2ndquadrant.com>
` Re: DB running out of memory issues after upgrade
2020-02-18 18:07 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: DB running out of memory issues after upgrade
2020-02-18 18:10 UTC Nagaraj Raj <nagaraj.sf@yahoo.com>
` Re: DB running out of memory issues after upgrade
2020-02-18 18:33 UTC Stephen Frost <sfrost@snowman.net>
` Re: DB running out of memory issues after upgrade
2020-02-18 18:38 UTC Merlin Moncure <mmoncure@gmail.com>
` Re: DB running out of memory issues after upgrade
2020-02-18 18:40 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: DB running out of memory issues after upgrade
2020-02-18 18:49 UTC Merlin Moncure <mmoncure@gmail.com>
` Re: DB running out of memory issues after upgrade
2020-02-18 19:10 UTC Nagaraj Raj <nagaraj.sf@yahoo.com>
` Re: DB running out of memory issues after upgrade
2020-02-23 10:19 UTC Peter J. Holzer <hjp-pgsql@hjp.at>
` Re: DB running out of memory issues after upgrade
2020-02-24 16:34 UTC Merlin Moncure <mmoncure@gmail.com>
[11+ messages in thread]
Can we have multiple tablespaces with in a database.
2020-02-21 05:34 UTC Daulat Ram <Daulat.Ram@exponential.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 05:46 UTC amul sul <sulamul@gmail.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 05:46 UTC David G. Johnston <david.g.johnston@gmail.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 06:00 UTC Ron <ronljohnsonjr@gmail.com>
` RE: Can we have multiple tablespaces with in a database.
2020-02-21 06:01 UTC Daulat Ram <Daulat.Ram@exponential.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 06:18 UTC amul sul <sulamul@gmail.com>
` RE: Can we have multiple tablespaces with in a database.
2020-02-21 06:23 UTC Daulat Ram <Daulat.Ram@exponential.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 06:26 UTC amul sul <sulamul@gmail.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 06:27 UTC Christophe Pettus <xof@thebuild.com>
` RE: Can we have multiple tablespaces with in a database.
2020-02-21 06:34 UTC Daulat Ram <Daulat.Ram@exponential.com>
` RE: Can we have multiple tablespaces with in a database.
2020-02-21 06:36 UTC Daulat Ram <Daulat.Ram@exponential.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 06:36 UTC Christophe Pettus <xof@thebuild.com>
` RE: Can we have multiple tablespaces with in a database.
2020-02-21 07:17 UTC Daulat Ram <Daulat.Ram@exponential.com>
` Re: Can we have multiple tablespaces with in a database.
2020-02-21 11:50 UTC amul sul <sulamul@gmail.com>
` RE: Can we have multiple tablespaces with in a database.
2020-02-21 16:24 UTC Patrick FICHE <Patrick.Fiche@aqsacom.com>
` RE: Can we have multiple tablespaces with in a database.
2020-02-22 04:45 UTC Daulat Ram <Daulat.Ram@exponential.com>
[16+ messages in thread]
tablespace to benefit from ssd ?
2020-02-19 04:42 UTC Nicolas PARIS <nicolas.paris@riseup.net>
` Re: tablespace to benefit from ssd ?
2020-02-19 08:02 UTC Sebastiaan Mannem <sebastiaan.mannem@enterprisedb.com>
` Re: tablespace to benefit from ssd ?
2020-02-19 10:48 UTC Laurenz Albe <laurenz.albe@cybertec.at>
` Re: tablespace to benefit from ssd ?
2020-02-19 13:08 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: tablespace to benefit from ssd ?
2020-02-20 17:30 UTC Jeff Janes <jeff.janes@gmail.com>
[5+ messages in thread]
SubtransControlLock and performance problems
2020-02-16 17:15 UTC Lars Aksel Opsahl <Lars.Opsahl@nibio.no>
` Re: SubtransControlLock and performance problems
2020-02-17 09:53 UTC Laurenz Albe <laurenz.albe@cybertec.at>
` Re: SubtransControlLock and performance problems
2020-02-17 15:03 UTC Lars Aksel Opsahl <Lars.Opsahl@nibio.no>
` Re: SubtransControlLock and performance problems
2020-02-17 16:35 UTC Laurenz Albe <laurenz.albe@cybertec.at>
` Re: SubtransControlLock and performance problems
2020-02-17 18:01 UTC Pavel Stehule <pavel.stehule@gmail.com>
` Re: SubtransControlLock and performance problems
2020-02-17 18:23 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: SubtransControlLock and performance problems
2020-02-17 18:41 UTC Pavel Stehule <pavel.stehule@gmail.com>
` Re: SubtransControlLock and performance problems
2020-02-17 19:10 UTC Alvaro Herrera <alvherre@2ndquadrant.com>
` Re: SubtransControlLock and performance problems
2020-02-18 17:27 UTC Laurenz Albe <laurenz.albe@cybertec.at>
` Re: SubtransControlLock and performance problems
2020-02-18 23:46 UTC Pavel Stehule <pavel.stehule@gmail.com>
` Re: SubtransControlLock and performance problems
2020-02-19 10:49 UTC Lars Aksel Opsahl <Lars.Opsahl@nibio.no>
` Re: SubtransControlLock and performance problems
2020-02-19 15:23 UTC Alvaro Herrera <alvherre@2ndquadrant.com>
` Re: SubtransControlLock and performance problems
2020-02-20 09:20 UTC Lars Aksel Opsahl <Lars.Opsahl@nibio.no>
[13+ messages in thread]
How to avoid UPDATE performance degradation in a transaction
2020-02-13 10:21 UTC Karl Düüna <karl.dyyna@gmail.com>
` Re: How to avoid UPDATE performance degradation in a transaction
2020-02-13 20:50 UTC David G. Johnston <david.g.johnston@gmail.com>
` Re: How to avoid UPDATE performance degradation in a transaction
2020-02-13 21:16 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: How to avoid UPDATE performance degradation in a transaction
2020-02-14 07:14 UTC Karl Düüna <karl.dyyna@gmail.com>
` Re: How to avoid UPDATE performance degradation in a transaction
2020-02-14 17:54 UTC Michael Lewis <mlewis@entrata.com>
` Re: How to avoid UPDATE performance degradation in a transaction
2020-02-20 04:35 UTC Andres Freund <andres@anarazel.de>
[6+ messages in thread]
Partial index creation always scans the entire table
2020-02-15 11:04 UTC MingJu Wu <mingjuwu0505@gmail.com>
` Re: Partial index creation always scans the entire table
2020-02-15 12:47 UTC Sergei Kornilov <sk@zsrv.org>
` Re: Partial index creation always scans the entire table
2020-02-15 12:53 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Partial index creation always scans the entire table
2020-02-15 21:15 UTC Laurenz Albe <laurenz.albe@cybertec.at>
` Re: Partial index creation always scans the entire table
2020-02-16 15:30 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Partial index creation always scans the entire table
2020-02-16 15:59 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Partial index creation always scans the entire table
2020-02-16 16:35 UTC Tom Lane <tgl@sss.pgh.pa.us>
` RE: Partial index creation always scans the entire table
2020-02-17 00:43 UTC Mike Sofen <msofen@runbox.com>
` Re: Partial index creation always scans the entire table
2020-02-17 00:52 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Partial index creation always scans the entire table
2020-02-17 01:09 UTC Tom Lane <tgl@sss.pgh.pa.us>
[10+ messages in thread]
Bad selectivity estimate when using a sub query to determine WHERE condition
2020-02-10 10:34 UTC Chris Borckholder <chris.borckholder@bitpanda.com>
` Re: Bad selectivity estimate when using a sub query to determine WHERE condition
2020-02-10 15:39 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Bad selectivity estimate when using a sub query to determine WHERE condition
2020-02-10 19:13 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Bad selectivity estimate when using a sub query to determine WHERE condition
2020-02-12 08:09 UTC Chris Borckholder <chris.borckholder@bitpanda.com>
` Re: Bad selectivity estimate when using a sub query to determine WHERE condition
2020-02-12 08:12 UTC Chris Borckholder <chris.borckholder@bitpanda.com>
[5+ messages in thread]
Writing 1100 rows per second
2020-02-05 17:03 UTC Arya F <arya6000@gmail.com>
` Re: Writing 1100 rows per second
2020-02-05 17:12 UTC Laurenz Albe <laurenz.albe@cybertec.at>
` Re: Writing 1100 rows per second
2020-02-05 17:15 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Writing 1100 rows per second
2020-02-05 17:25 UTC Arya F <arya6000@gmail.com>
` Re: Writing 1100 rows per second
2020-02-05 17:46 UTC Haroldo Kerry <hkerry@callix.com.br>
` Re: Writing 1100 rows per second
2020-02-06 18:15 UTC Ogden Brash <obrash@litika.com>
` Re: Writing 1100 rows per second
2020-02-09 19:30 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Writing 1100 rows per second
2020-02-12 05:28 UTC Amol Tarte <amoltarte@gmail.com>
[8+ messages in thread]
TOAST table performance problem
2020-02-07 13:07 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
` Re: TOAST table performance problem
2020-02-07 13:23 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
` Re: TOAST table performance problem
2020-02-07 13:34 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
` Re: TOAST table performance problem
2020-02-07 13:41 UTC Andreas Joseph Krogh <andreas@visena.com>
` Re: TOAST table performance problem
2020-02-07 13:52 UTC MichaelDBA <MichaelDBA@sqlexec.com>
` Re: TOAST table performance problem
2020-02-07 14:16 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
` Re: TOAST table performance problem
2020-02-07 14:19 UTC Andreas Joseph Krogh <andreas@visena.com>
` Re: TOAST table performance problem
2020-02-07 14:42 UTC Andreas Joseph Krogh <andreas@visena.com>
` Re: TOAST table performance problem
2020-02-07 14:59 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
` Re: TOAST table performance problem
2020-02-07 15:15 UTC Andreas Joseph Krogh <andreas@visena.com>
` Fwd: TOAST table performance problem
2020-02-10 07:52 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
` Re: Fwd: TOAST table performance problem
2020-02-10 12:31 UTC Luís Roberto Weck <luisroberto@siscobra.com.br>
` Re: Fwd: TOAST table performance problem
2020-02-10 12:38 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
` Re: Fwd: TOAST table performance problem
2020-02-10 12:53 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Fwd: TOAST table performance problem
2020-02-10 12:59 UTC Asya Nevra Buyuksoy <ayisan1096@gmail.com>
[15+ messages in thread]
Sv: TOAST table performance problem
2020-02-07 13:12 UTC Andreas Joseph Krogh <andreas@visena.com>
Slow performance with trivial self-joins
2020-02-03 20:38 UTC Benny Kramek <benny@medflyt.com>
` Re: Slow performance with trivial self-joins
2020-02-03 21:10 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Slow performance with trivial self-joins
2020-02-05 21:55 UTC Benny Kramek <benny@medflyt.com>
` Re: Slow performance with trivial self-joins
2020-02-05 22:12 UTC Adam Brusselback <adambrusselback@gmail.com>
` Re: Slow performance with trivial self-joins
2020-02-05 23:47 UTC David Rowley <david.rowley@2ndquadrant.com>
[5+ messages in thread]
Statistics on array values
2020-02-02 14:18 UTC Marco Colli <collimarco91@gmail.com>
` Re: Statistics on array values
2020-02-02 14:23 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Statistics on array values
2020-02-02 14:38 UTC Marco Colli <collimarco91@gmail.com>
` Re: Statistics on array values
2020-02-02 17:11 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Statistics on array values
2020-02-02 18:26 UTC Marco Colli <collimarco91@gmail.com>
` Re: Statistics on array values
2020-02-02 18:32 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Statistics on array values
2020-02-02 18:55 UTC Marco Colli <collimarco91@gmail.com>
[7+ messages in thread]
Specific query taking time to process
2019-12-07 20:05 UTC Fahiz Mohamed <fahiz@netwidz.com>
` Re: Specific query taking time to process
2019-12-09 04:13 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Specific query taking time to process
2019-12-09 19:03 UTC Michael Lewis <mlewis@entrata.com>
` Re: Specific query taking time to process
2019-12-09 22:39 UTC Fahiz Mohamed <fahiz@netwidz.com>
` Re: Specific query taking time to process
2019-12-10 20:15 UTC Michael Lewis <mlewis@entrata.com>
` Re: Specific query taking time to process
2019-12-10 20:42 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Specific query taking time to process
2019-12-11 19:53 UTC Fahiz Mohamed <fahiz@netwidz.com>
` Re: Specific query taking time to process
2019-12-11 20:09 UTC Michael Lewis <mlewis@entrata.com>
` Re: Specific query taking time to process
2019-12-11 21:14 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Specific query taking time to process
2019-12-12 02:25 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Specific query taking time to process
2020-01-30 09:44 UTC Fahiz Mohamed <fahiz@netwidz.com>
` Re: Specific query taking time to process
2020-01-30 12:22 UTC Duncan Whitham <dwhitham@zaizi.com>
` Re: Specific query taking time to process
2020-01-30 16:35 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Specific query taking time to process
2020-01-31 11:01 UTC Duncan Whitham <dwhitham@zaizi.com>
[14+ messages in thread]
Query optimization advice for beginners
2020-01-27 13:15 UTC Kemal Ortanca <kemal.ortanca@outlook.com>
` Re: Query optimization advice for beginners
2020-01-27 13:57 UTC Andreas Kretschmer <andreas@a-kretschmer.de>
` Re: Query optimization advice for beginners
2020-01-27 15:33 UTC Kemal Ortanca <kemal.ortanca@outlook.com>
` Re: Query optimization advice for beginners
2020-01-27 16:46 UTC Michael Lewis <mlewis@entrata.com>
` Re: Query optimization advice for beginners
2020-01-28 08:37 UTC Laurenz Albe <laurenz.albe@cybertec.at>
[5+ messages in thread]
Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 14:06 UTC Cosmin Prund <cprund@gmail.com>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 15:11 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 16:59 UTC Michael Lewis <mlewis@entrata.com>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 17:18 UTC Cosmin Prund <cprund@gmail.com>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 17:27 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 18:15 UTC Cosmin Prund <cprund@gmail.com>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 18:20 UTC Laurenz Albe <laurenz.albe@cybertec.at>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 18:23 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 18:52 UTC Michael Lewis <mlewis@entrata.com>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 18:55 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 19:06 UTC Cosmin Prund <cprund@gmail.com>
` Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
2020-01-16 19:52 UTC Cosmin Prund <cprund@gmail.com>
[12+ messages in thread]
Queries in plpgsql are 6 times slower on partitioned tables
2020-01-16 13:21 UTC Marcin Barczyński <mba.ogolny@gmail.com>
shared buffers and startup process
2020-01-14 15:29 UTC Joao Junior <jcoj2006@gmail.com>
` Re: shared buffers and startup process
2020-01-15 02:48 UTC Michael Paquier <michael@paquier.xyz>
[2+ messages in thread]
Bad query plan when you add many OR conditions
2020-01-10 01:11 UTC Marco Colli <collimarco91@gmail.com>
` Re: Bad query plan when you add many OR conditions
2020-01-10 03:06 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Bad query plan when you add many OR conditions
2020-01-10 11:03 UTC Marco Colli <collimarco91@gmail.com>
` Re: Bad query plan when you add many OR conditions
2020-01-10 13:30 UTC Marco Colli <collimarco91@gmail.com>
` Re: Bad query plan when you add many OR conditions
2020-01-10 13:34 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Bad query plan when you add many OR conditions
2020-01-10 14:53 UTC Marco Colli <collimarco91@gmail.com>
` Re: Bad query plan when you add many OR conditions
2020-01-10 15:18 UTC Tom Lane <tgl@sss.pgh.pa.us>
` Re: Bad query plan when you add many OR conditions
2020-01-10 16:03 UTC Marco Colli <collimarco91@gmail.com>
` Re: Bad query plan when you add many OR conditions
2020-01-10 17:12 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: Bad query plan when you add many OR conditions
2020-01-13 22:14 UTC Tomas Vondra <tomas.vondra@2ndquadrant.com>
` Re: Bad query plan when you add many OR conditions
2020-01-14 08:01 UTC Thomas Kellerer <spam_eater@gmx.net>
[11+ messages in thread]
Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 16:29 UTC Shira Bezalel <shira@sfei.org>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 16:42 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 17:34 UTC Shira Bezalel <shira@sfei.org>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 18:07 UTC Michael Lewis <mlewis@entrata.com>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 20:44 UTC Shira Bezalel <shira@sfei.org>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 21:11 UTC Tomas Vondra <tomas.vondra@2ndquadrant.com>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 21:45 UTC Shira Bezalel <shira@sfei.org>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-13 22:15 UTC Alvaro Herrera <alvherre@2ndquadrant.com>
` Re: Seeking reason behind performance gain in 12 with HashAggregate
2020-01-14 00:11 UTC Shira Bezalel <shira@sfei.org>
[9+ messages in thread]
doc: alter table references bogus table-specific planner parameters
2020-01-06 02:56 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: doc: alter table references bogus table-specific planner parameters
2020-01-06 03:48 UTC Simon Riggs <simon@2ndquadrant.com>
` Re: doc: alter table references bogus table-specific planner parameters
2020-01-06 04:13 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: doc: alter table references bogus table-specific planner parameters
2020-01-06 04:33 UTC Simon Riggs <simon@2ndquadrant.com>
[4+ messages in thread]
[PATCH v1] Fixes for commit 6f3a13ff
2020-01-06 01:39 UTC Justin Pryzby <pryzbyj@telsasoft.com>
allow disabling indexscans without disabling bitmapscans
2020-01-04 16:50 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: allow disabling indexscans without disabling bitmapscans
2020-01-04 19:34 UTC Justin Pryzby <pryzby@telsasoft.com>
[2+ messages in thread]
[PATCH v1] allow disabling indexscans but not bitmap scans
2020-01-04 16:25 UTC Justin Pryzby <pryzbyj@telsasoft.com>
distinguish index cost component from table component
2020-01-03 14:14 UTC Justin Pryzby <pryzby@telsasoft.com>
` Re: distinguish index cost component from table component
2020-01-03 14:33 UTC Jeff Janes <jeff.janes@gmail.com>
` Re: distinguish index cost component from table component
2020-01-03 16:03 UTC Justin Pryzby <pryzby@telsasoft.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