pgsql-performance 2010-01 Thread Index (1/4)

Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Text Size: Normal / Large
Donate
Contact

Header And Logo

PostgreSQL

|

The world's most advanced open source database.

Site Navigation

pgsql-performance 2010-01 Thread Index (1/4)

Last updated: Wed Jan 18 04:14:09 2012
541 messages

Main Index
[Prev Page]
[Next Page]

Slow query: table iteration (8.3) Glenn Maynard (Sat 30 03:55)
Limited Shared Buffer Problem **Rod MacNeil (Fri 29 16:46)

Re: Limited Shared Buffer Problem Richard Neill (Fri 29 16:53)

Re: Limited Shared Buffer Problem Ing . Marcos Luís Ortíz Valmaseda (Fri 29 17:21)
Re: Limited Shared Buffer Problem Cédric Villemain (Fri 29 18:19)

Re: Limited Shared Buffer Problem Greg Smith (Fri 29 22:19)

Re: Limited Shared Buffer Problem **Rod MacNeil (Fri 29 18:36)

Re: Limited Shared Buffer Problem Scott Marlowe (Fri 29 17:18)
Re: Limited Shared Buffer Problem jose javier parra sanchez (Fri 29 17:46)

Constraint propagating for equal fields Віталій Тимчишин (Thu 28 11:21)

Re: Constraint propagating for equal fields Greg Stark (Sat 30 02:30)

test send (recommended by Dave Page) Mark Steben (Wed 27 15:33)

Re: test send (recommended by Dave Page) Matthew Wakeling (Wed 27 15:37)
Re: test send (recommended by Dave Page) Dave Page (Wed 27 15:44)

Benchmark shows very slow bulk delete Thom Brown (Wed 27 13:28)

Re: Benchmark shows very slow bulk delete Ivan Voras (Wed 27 14:24)

Re: Benchmark shows very slow bulk delete James Mansion (Wed 27 21:26)

Re: Benchmark shows very slow bulk delete Ivan Voras (Thu 28 10:53)

Re: Benchmark shows very slow bulk delete Matthew Wakeling (Wed 27 14:49)

Re: Benchmark shows very slow bulk delete Andres Freund (Wed 27 15:56)

Re: Benchmark shows very slow bulk delete Kevin Grittner (Wed 27 14:54)

Re: Benchmark shows very slow bulk delete Nikolas Everett (Wed 27 15:38)
Re: Benchmark shows very slow bulk delete Greg Smith (Wed 27 21:41)

Should the optimiser convert a CASE into a WHERE if it can? Richard Neill (Tue 26 17:10)

Re: Should the optimiser convert a CASE into a WHERE if it can? Tom Lane (Tue 26 17:21)

Re: Should the optimiser convert a CASE into a WHERE if it can? Richard Neill (Tue 26 17:42)

Re: Should the optimiser convert a CASE into a WHERE if it can? Scott Carey (Tue 26 21:33)

Re: Should the optimiser convert a CASE into a WHERE if it can? Matthew Wakeling (Tue 26 17:23)

Re: Should the optimiser convert a CASE into a WHERE if it can? Віталій Тимчишин (Wed 27 16:53)

Re: Should the optimiser convert a CASE into a WHERE if it can? Matthew Wakeling (Wed 27 17:01)

Re: Should the optimiser convert a CASE into a WHERE if it can? Віталій Тимчишин (Wed 27 17:11)

Poor query plan across OR operator Mark Hills (Tue 26 16:07)

Re: Poor query plan across OR operator Grzegorz Jaśkiewicz (Tue 26 16:10)
Re: Poor query plan across OR operator Tom Lane (Tue 26 16:42)

Re: Poor query plan across OR operator Robert Haas (Tue 26 19:35)

Re: Poor query plan across OR operator Tom Lane (Tue 26 20:48)

Re: Poor query plan across OR operator Kevin Grittner (Tue 26 21:05)

splitting data into multiple tables nair rajiv (Mon 25 17:23)

Re: splitting data into multiple tables Amitabh Kant (Mon 25 17:34)
Re: splitting data into multiple tables Viji V Nair (Mon 25 17:39)

Re: splitting data into multiple tables Matthew Wakeling (Tue 26 11:42)

Re: splitting data into multiple tables Kevin Grittner (Mon 25 17:47)

Re: splitting data into multiple tables Craig James (Mon 25 20:15)

Re: splitting data into multiple tables nair rajiv (Tue 26 00:40)

Re: splitting data into multiple tables Andres Freund (Tue 26 00:49)

Re: splitting data into multiple tables nair rajiv (Tue 26 03:49)
Re: splitting data into multiple tables Viji V Nair (Tue 26 07:58)
Re: splitting data into multiple tables Greg Smith (Tue 26 17:41)
Re: splitting data into multiple tables Viji V Nair (Tue 26 18:23)
Re: splitting data into multiple tables Greg Smith (Tue 26 20:32)

Re: splitting data into multiple tables Matthew Wakeling (Tue 26 11:45)

Re: splitting data into multiple tables nair rajiv (Tue 26 15:18)

Sql result b where condition ramasubramanian (Mon 25 10:02)

Re: Sql result b where condition A. Kretschmer (Mon 25 10:16)

Re: Sql result b where condition Matthew Wakeling (Mon 25 12:10)

Re: Sql result b where condition A. Kretschmer (Mon 25 12:24)

Fragmentation/Vacuum, Analyze, Re-Index DM (Fri 22 08:11)

Re: Fragmentation/Vacuum, Analyze, Re-Index DM (Fri 22 17:11)

Re: Fragmentation/Vacuum, Analyze, Re-Index Richard Neill (Fri 22 19:28)

Re: Fragmentation/Vacuum, Analyze, Re-Index Reid Thompson (Sat 23 07:29)

TPC-C implementation for postgresql? tmp (Thu 21 23:17)

Re: TPC-C implementation for postgresql? Greg Smith (Fri 22 00:10)

Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (Thu 21 22:15)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Craig Ringer (Fri 22 03:46)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (Fri 22 17:59)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Scott Marlowe (Fri 22 18:38)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Craig Ringer (Sat 23 02:25)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Richard Huxton (Fri 22 09:43)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (Fri 22 18:03)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Richard Huxton (Fri 22 18:25)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Matthew Wakeling (Fri 22 18:27)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (Fri 22 19:06)

Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (Fri 22 19:08)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Richard Huxton (Mon 25 10:54)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Matthew Wakeling (Mon 25 11:59)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (Mon 25 22:17)

Slow update query elias ghanem (Thu 21 15:24)

Re: Slow update query Kevin Grittner (Thu 21 15:43)
<Possible follow-ups>
Slow update query elias ghanem (Thu 21 17:33)

Re: Slow update query Kevin Grittner (Thu 21 18:44)
Re: Slow update query Craig Ringer (Fri 22 03:22)
Re: Slow update query Robert Haas (Fri 22 15:05)

Slow update query elias ghanem (Fri 22 12:40)

performance question on VACUUM FULL (Postgres 8.4.2) PG User 2010 (Tue 19 20:19)

Re: performance question on VACUUM FULL (Postgres 8.4.2) Jeff Davis (Tue 19 22:38)

Re: performance question on VACUUM FULL (Postgres 8.4.2) PG User 2010 (Thu 21 22:43)

renice on an I/O bound box Willy-Bas Loos (Tue 19 12:59)

Re: renice on an I/O bound box Ing. Marcos L. Ortiz Valmaseda (Tue 19 16:11)
Message not available
- Message not available
  - Message not available
    - Re: renice on an I/O bound box Willy-Bas Loos (Tue 19 17:07)
Re: renice on an I/O bound box Arjen van der Meijden (Tue 19 20:16)

Re: renice on an I/O bound box Craig Ringer (Wed 20 01:19)

Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (Mon 18 16:36)

Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (Tue 19 14:52)

Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (Tue 19 14:57)

Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (Wed 20 04:13)
Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Smith (Wed 20 05:21)
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Smith (Wed 27 07:22)

Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (Tue 19 15:03)
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Tom Lane (Tue 19 15:26)

Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (Fri 29 18:56)

Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (Wed 20 04:02)

Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (Wed 20 04:02)

ext4 finally doing the right thing Greg Smith (Sat 16 03:06)

Re: ext4 finally doing the right thing Jeff Davis (Tue 19 23:53)

Re: ext4 finally doing the right thing Greg Smith (Wed 20 21:19)

Re: ext4 finally doing the right thing Greg Stark (Thu 21 05:15)

Re: ext4 finally doing the right thing Greg Smith (Thu 21 05:58)

Re: ext4 finally doing the right thing Greg Stark (Thu 21 11:13)
Re: ext4 finally doing the right thing Aidan Van Dyk (Thu 21 13:51)
Re: ext4 finally doing the right thing Greg Smith (Thu 21 14:49)
Re: ext4 finally doing the right thing Aidan Van Dyk (Thu 21 15:05)
Re: ext4 finally doing the right thing Pierre Frédéric Caillau d (Thu 21 16:35)
Re: ext4 finally doing the right thing Greg Smith (Fri 22 00:15)
Re: ext4 finally doing the right thing Kevin Grittner (Thu 21 15:54)
Re: ext4 finally doing the right thing Florian Weimer (Thu 21 14:04)

Bad plan choice nestloop vs. hashjoin Kenneth Marshall (Fri 15 22:53)

Re: Bad plan choice nestloop vs. hashjoin Kevin Grittner (Fri 15 22:59)

Re: Bad plan choice nestloop vs. hashjoin Kenneth Marshall (Sat 16 00:14)

Re: Bad plan choice nestloop vs. hashjoin Tom Lane (Sat 16 00:27)
Re: Bad plan choice nestloop vs. hashjoin Tom Lane (Mon 18 17:13)

Re: Bad plan choice nestloop vs. hashjoin Kenneth Marshall (Mon 18 18:57)

OT: Db2 connection pooling? Alan McKay (Fri 15 17:16)

Re: OT: Db2 connection pooling? Alan McKay (Fri 15 17:16)

New server to improve performance on our large and busy DB - advice? (v2) Carlo Stonebanks (Thu 14 21:45)

Re: New server to improve performance on our large and busy DB - advice? (v2) Dave Crooke (Thu 14 22:36)

Re: New server to improve performance on our large and busy DB - advice? (v2) Craig Ringer (Fri 15 00:46)

Re: New server to improve performance on our large and busy DB - advice? (v2) Dave Crooke (Sat 16 01:49)

Re: New server to improve performance on our large and busy DB - advice? (v2) Tom Lane (Sat 16 02:05)
Re: New server to improve performance on our large and busy DB - advice? (v2) Greg Smith (Sat 16 02:09)

Re: New server to improve performance on our large and busy DB - advice? (v2) Tony McC (Fri 15 16:17)

Re: New server to improve performance on our large and busy DB - advice? (v2) Richard Broersma (Fri 15 16:20)

Re: New server to improve performance on our large and busy DB - advice? (v2) Tom Lane (Fri 15 16:55)

Re: New server to improve performance on our large and busy DB - advice? (v2) Greg Smith (Fri 15 18:29)
Re: New server to improve performance on our large and busy DB - advice? (v2) Scott Marlowe (Fri 15 21:39)
Re: New server to improve performance on our large and busy DB - advice? (v2) Kevin Grittner (Fri 15 21:55)

Re: New server to improve performance on our large and busy DB - advice? (v2) Robert Haas (Fri 15 16:23)
Re: New server to improve performance on our large and busy DB - advice? (v2) Dave Crooke (Sat 16 01:38)

Re: New server to improve performance on our large and busy DB - advice? (v2) Ivan Voras (Fri 15 13:43)

Re: Re: New server to improve performance on our large and busy DB - advice? (v2) Robert Haas (Fri 15 14:42)
Re: Re: New server to improve performance on our large and busy DB - advice? (v2) Ing. Marcos L. Ortiz Valmaseda (Fri 15 15:18)
Re: Re: New server to improve performance on our large and busy DB - advice? (v2) Pierre Frédéric Caillau d (Fri 15 16:46)
Re: Re: New server to improve performance on our large and busy DB - advice? (v2) Carlo Stonebanks (Wed 20 22:47)

new server I/O setup Fernando Hevia (Thu 14 20:03)

Re: new server I/O setup Scott Marlowe (Thu 14 21:24)

Re: new server I/O setup Matthew Wakeling (Fri 15 11:21)

Re: new server I/O setup Fernando Hevia (Fri 15 17:03)

Re: new server I/O setup Matthew Wakeling (Fri 15 17:15)

Re: new server I/O setup Pierre Frédéric Caillau d (Fri 15 17:59)
Re: new server I/O setup Fernando Hevia (Fri 15 19:35)
Re: new server I/O setup Scott Marlowe (Fri 15 21:42)

Re: new server I/O setup Fernando Hevia (Fri 15 15:48)

Re: new server I/O setup Greg Smith (Fri 15 05:46)

Re: new server I/O setup Fernando Hevia (Fri 15 16:50)

bad execution plan for subselects containing windowing-function Andreas Kretschmer (Thu 14 17:03)

Re: bad execution plan for subselects containing windowing-function Tom Lane (Thu 14 17:15)

Re: bad execution plan for subselects containing windowing-function Andreas Kretschmer (Thu 14 17:30)

Re: bad execution plan for subselects containing windowing-function Tom Lane (Thu 14 17:42)

Re: bad execution plan for subselects containing windowing-function Andreas Kretschmer (Thu 14 18:04)

Re: bad execution plan for subselects containing windowing-function Andreas Kretschmer (Thu 14 18:31)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Kevin Grittner (Thu 14 15:48)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Ivan Voras (Thu 14 16:01)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Kevin Grittner (Thu 14 16:03)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Greg Smith (Thu 14 18:02)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Kevin Grittner (Thu 14 18:12)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Greg Smith (Thu 14 18:25)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Kevin Grittner (Thu 14 18:34)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Greg Smith (Thu 14 18:50)

Slow "Select count(*) ..." query on table with 60 Mio. rows tom (Thu 14 14:59)

Re: Slow "Select count(*) ..." query on table with 60 Mio. rows Matthew Wakeling (Thu 14 15:12)
Re: Slow "Select count(*) ..." query on table with 60 Mio. rows A. Kretschmer (Thu 14 15:18)

Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (Thu 14 14:29)

Re: Inserting 8MB bytea: just 25% of disk perf used? Ivan Voras (Thu 14 14:49)

Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (Thu 14 20:10)

Re: Inserting 8MB bytea: just 25% of disk perf used? Matthew Wakeling (Thu 14 15:04)

Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (Thu 14 20:19)

Re: Inserting 8MB bytea: just 25% of disk perf used? Matthew Wakeling (Fri 15 11:09)

Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (Mon 18 16:13)
Re: Inserting 8MB bytea: just 25% of disk perf used? Florian Weimer (Thu 21 16:24)

Re: Inserting 8MB bytea: just 25% of disk perf used? Aidan Van Dyk (Thu 14 15:07)

Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (Thu 14 21:24)

Main Index
[Prev Page]
[Next Page]

Mail converted by MHonArc

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group