Skip site navigation (1)
Skip section navigation (2)
541 messages
29 January 2010
Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (18:56)
Re: Limited Shared Buffer Problem **Rod MacNeil (18:36)
Re: Limited Shared Buffer Problem Cédric Villemain (18:19)
Re: Limited Shared Buffer Problem jose javier parra sanchez (17:46)
Re: Limited Shared Buffer Problem Ing . Marcos Luís Ortíz Valmaseda (17:21)
Re: Limited Shared Buffer Problem Scott Marlowe (17:18)
Re: Limited Shared Buffer Problem Richard Neill (16:53)
Limited Shared Buffer Problem **Rod MacNeil (16:46)
28 January 2010
Re: Benchmark shows very slow bulk delete Ivan Voras (10:53)
27 January 2010
Re: Benchmark shows very slow bulk delete James Mansion (21:26)
Re: Should the optimiser convert a CASE into a WHERE if it can? Віталій Тимчишин (17:11)
Re: Should the optimiser convert a CASE into a WHERE if it can? Matthew Wakeling (17:01)
Re: Should the optimiser convert a CASE into a WHERE if it can? Віталій Тимчишин (16:53)
Re: Benchmark shows very slow bulk delete Andres Freund (15:56)
Re: test send (recommended by Dave Page) Dave Page (15:44)
Re: Benchmark shows very slow bulk delete Nikolas Everett (15:38)
Re: test send (recommended by Dave Page) Matthew Wakeling (15:37)
test send (recommended by Dave Page) Mark Steben (15:33)
Re: Benchmark shows very slow bulk delete Kevin Grittner (14:54)
Re: Benchmark shows very slow bulk delete Matthew Wakeling (14:49)
Re: Benchmark shows very slow bulk delete Ivan Voras (14:24)
Benchmark shows very slow bulk delete Thom Brown (13:28)
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Smith (07:22)
26 January 2010
Re: New server to improve performance on our large and busy DB - advice? Greg Smith (21:53)
Re: Should the optimiser convert a CASE into a WHERE if it can? Scott Carey (21:33)
Re: Inserting 8MB bytea: just 25% of disk perf used? Scott Carey (21:28)
Re: Poor query plan across OR operator Kevin Grittner (21:05)
Re: Poor query plan across OR operator Tom Lane (20:48)
Re: splitting data into multiple tables Greg Smith (20:32)
Re: Poor query plan across OR operator Robert Haas (19:35)
Re: splitting data into multiple tables Viji V Nair (18:23)
Re: Should the optimiser convert a CASE into a WHERE if it can? Richard Neill (17:42)
Re: splitting data into multiple tables Greg Smith (17:41)
Re: Should the optimiser convert a CASE into a WHERE if it can? Matthew Wakeling (17:23)
Re: Should the optimiser convert a CASE into a WHERE if it can? Tom Lane (17:21)
Should the optimiser convert a CASE into a WHERE if it can? Richard Neill (17:10)
Re: Poor query plan across OR operator Tom Lane (16:42)
Re: Poor query plan across OR operator Grzegorz Jaśkiewicz (16:10)
Poor query plan across OR operator Mark Hills (16:07)
Re: splitting data into multiple tables nair rajiv (15:18)
Re: splitting data into multiple tables Matthew Wakeling (11:45)
Re: splitting data into multiple tables Matthew Wakeling (11:42)
Re: splitting data into multiple tables Viji V Nair (07:58)
Re: splitting data into multiple tables nair rajiv (03:49)
Re: splitting data into multiple tables Andres Freund (00:49)
Re: splitting data into multiple tables nair rajiv (00:40)
25 January 2010
Re: splitting data into multiple tables Craig James (20:15)
Re: splitting data into multiple tables Kevin Grittner (17:47)
Re: splitting data into multiple tables Viji V Nair (17:39)
Re: splitting data into multiple tables Amitabh Kant (17:34)
splitting data into multiple tables nair rajiv (17:23)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (14:55)
Re: Sql result b where condition A. Kretschmer (12:24)
Re: Sql result b where condition Matthew Wakeling (12:10)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Matthew Wakeling (11:59)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Richard Huxton (10:54)
Re: Sql result b where condition A. Kretschmer (10:16)
Sql result b where condition ramasubramanian (10:02)
23 January 2010
Re: Inserting 8MB bytea: just 25% of disk perf used? Scott Carey (03:31)
Re: Inserting 8MB bytea: just 25% of disk perf used? Scott Carey (02:53)
Re: Inserting 8MB bytea: just 25% of disk perf used? Scott Carey (02:52)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Craig Ringer (02:25)
22 January 2010
Re: Fragmentation/Vacuum, Analyze, Re-Index Richard Neill (19:28)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (19:08)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (19:06)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Scott Marlowe (18:38)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Matthew Wakeling (18:27)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Richard Huxton (18:25)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (18:03)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (17:59)
Re: New server to improve performance on our large and busy DB - advice? Carlo Stonebanks (17:47)
Re: Fragmentation/Vacuum, Analyze, Re-Index DM (17:11)
Re: Slow update query Robert Haas (15:05)
Slow update query elias ghanem (12:40)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Richard Huxton (09:43)
Fragmentation/Vacuum, Analyze, Re-Index DM (08:11)
Re: Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Craig Ringer (03:46)
Re: Slow update query Craig Ringer (03:22)
Re: ext4 finally doing the right thing Greg Smith (00:15)
Re: TPC-C implementation for postgresql? Greg Smith (00:10)
21 January 2010
Re: performance question on VACUUM FULL (Postgres 8.4.2) PG User 2010 (22:43)
Data Set Growth causing 26+hour runtime, on what we believe to be very simple SQL Tory M Blue (22:15)
Re: New server to improve performance on our large and busy DB - advice? Devrim GÜNDÜZ (19:45)
Re: Slow update query Kevin Grittner (18:44)
Slow update query elias ghanem (17:33)
Re: New server to improve performance on our large and busy DB - advice? Scott Marlowe (16:50)
Re: New server to improve performance on our large and busy DB - advice? Alvaro Herrera (16:45)
Re: New server to improve performance on our large and busy DB - advice? Scott Marlowe (16:41)
Re: ext4 finally doing the right thing Pierre Frédéric Caillau d (16:35)
Re: Inserting 8MB bytea: just 25% of disk perf used? Florian Weimer (16:24)
Re: ext4 finally doing the right thing Kevin Grittner (15:54)
Re: New server to improve performance on our large and busy DB - advice? Alvaro Herrera (15:52)
Re: Slow update query Kevin Grittner (15:43)
Slow update query elias ghanem (15:24)
Re: ext4 finally doing the right thing Aidan Van Dyk (15:05)
Re: ext4 finally doing the right thing Greg Smith (14:49)
Re: ext4 finally doing the right thing Florian Weimer (14:04)
Re: ext4 finally doing the right thing Aidan Van Dyk (13:51)
Re: Inserting 8MB bytea: just 25% of disk perf used? Matthew Wakeling (12:13)
Re: a heavy duty operation on an "unused" table kills my server Matthew Wakeling (12:03)
Re: ext4 finally doing the right thing Greg Stark (11:13)
Re: Inserting 8MB bytea: just 25% of disk perf used? Greg Smith (08:35)
Re: Inserting 8MB bytea: just 25% of disk perf used? Scott Carey (08:26)
Re: ext4 finally doing the right thing Greg Smith (05:58)
Re: ext4 finally doing the right thing Greg Stark (05:15)
Re: New server to improve performance on our large and busy DB - advice? Robert Haas (02:03)
20 January 2010
Re: ext4 finally doing the right thing Greg Smith (21:19)
Re: New server to improve performance on our large and busy DB - advice? Kevin Grittner (20:37)
Re: a heavy duty operation on an "unused" table kills my server Greg Smith (20:34)
Re: New server to improve performance on our large and busy DB - advice? Carlo Stonebanks (20:17)
Re: Change query join order Kaloyan Iliev Iliev (16:07)
Re: a heavy duty operation on an "unused" table kills my server Matthew Wakeling (13:39)
Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Smith (05:21)
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (04:13)
Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (04:02)
Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (04:02)
Re: renice on an I/O bound box Craig Ringer (01:19)
19 January 2010
Re: New server to improve performance on our large and busy DB - advice? Scott Marlowe (22:57)
Re: performance question on VACUUM FULL (Postgres 8.4.2) Jeff Davis (22:38)
Re: New server to improve performance on our large and busy DB - advice? Carlo Stonebanks (21:16)
Re: Inserting 8MB bytea: just 25% of disk perf used? Scott Carey (20:32)
performance question on VACUUM FULL (Postgres 8.4.2) PG User 2010 (20:19)
Re: renice on an I/O bound box Arjen van der Meijden (20:16)
Re: renice on an I/O bound box Willy-Bas Loos (17:07)
Re: renice on an I/O bound box Ing. Marcos L. Ortiz Valmaseda (16:11)
Re: Inserting 8MB bytea: just 25% of disk perf used? Ivan Voras (15:40)
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Tom Lane (15:26)
Re: Inserting 8MB bytea: just 25% of disk perf used? Kevin Grittner (15:14)
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund (15:03)
Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (14:57)
Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (14:52)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (13:36)
renice on an I/O bound box Willy-Bas Loos (12:59)
Re: Inserting 8MB bytea: just 25% of disk perf used? Richard Huxton (12:26)
Re: Inserting 8MB bytea: just 25% of disk perf used? Ivan Voras (11:52)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (10:55)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (10:50)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (10:16)
18 January 2010
Re: Bad plan choice nestloop vs. hashjoin Kenneth Marshall (18:57)
Re: Bad plan choice nestloop vs. hashjoin Tom Lane (17:13)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (16:38)
Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark (16:36)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (16:13)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (16:04)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (13:25)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (13:08)
Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (11:21)
17 January 2010
Re: a heavy duty operation on an "unused" table kills my server Greg Smith (23:00)
Re: a heavy duty operation on an "unused" table kills my server Eduardo Piombino (21:23)
16 January 2010
Re: a heavy duty operation on an "unused" table kills my server Greg Smith (17:47)
Re: a heavy duty operation on an "unused" table kills my server Robert Haas (12:49)
Re: a heavy duty operation on an "unused" table kills my server Greg Smith (09:09)
Re: a heavy duty operation on an "unused" table kills my server Tom Lane (05:18)
Re: a heavy duty operation on an "unused" table kills my server Greg Smith (04:44)
Re: a heavy duty operation on an "unused" table kills my server Craig Ringer (04:00)
ext4 finally doing the right thing Greg Smith (03:06)
Re: a heavy duty operation on an "unused" table kills my server Greg Smith (02:25)
Re: New server to improve performance on our large and busy DB - advice? (v2) Greg Smith (02:09)
Re: New server to improve performance on our large and busy DB - advice? (v2) Tom Lane (02:05)
Re: New server to improve performance on our large and busy DB - advice? (v2) Dave Crooke (01:49)
Re: New server to improve performance on our large and busy DB - advice? (v2) Dave Crooke (01:38)
Re: a heavy duty operation on an "unused" table kills my server Eduardo Piombino (00:47)
Re: Bad plan choice nestloop vs. hashjoin Tom Lane (00:27)
Re: Bad plan choice nestloop vs. hashjoin Kenneth Marshall (00:14)
Re: Inserting 8MB bytea: just 25% of disk perf used? Dave Crooke (00:04)
Peripheral Links
Header And Logo
|
Site Navigation
pgsql-performance 2010-01 Chronological Index (1/4)
Last updated: Wed Jan 18 04:14:08 2012541 messages
- Thread Index
- [Prev Page]
- [Next Page]
- 30 January 2010
- Slow query: table iteration (8.3) Glenn Maynard (03:55)
- Re: Constraint propagating for equal fields Greg Stark (02:30)
- Re: Limited Shared Buffer Problem Greg Smith (22:19)
- Constraint propagating for equal fields Віталій Тимчишин (11:21)
- Re: Benchmark shows very slow bulk delete Greg Smith (21:41)
- Re: Inserting 8MB bytea: just 25% of disk perf used? Greg Smith (22:02)
- Re: Fragmentation/Vacuum, Analyze, Re-Index Reid Thompson (07:29)
- Re: Inserting 8MB bytea: just 25% of disk perf used? fkater(at)googlemail(dot)com (20:42)
- TPC-C implementation for postgresql? tmp (23:17)
- Re: Re: New server to improve performance on our large and busy DB - advice? (v2) Carlo Stonebanks (22:47)
- Re: ext4 finally doing the right thing Jeff Davis (23:53)
- Re: Inserting 8MB bytea: just 25% of disk perf used? Scott Carey (23:48)
- Re: a heavy duty operation on an "unused" table kills my server Tom Lane (23:14)
- Re: Inserting 8MB bytea: just 25% of disk perf used? Pierre Frédéric Caillau d (23:22)
- Thread Index
- [Prev Page]
- [Next Page]