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

Peripheral Links

Text Size: Normal / Large
Donate
Contact

PostgreSQL

The world's most advanced open source database.

pgsql-performance - July 2012

Prev | Next

Jump to day: 1 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 23 24 25 26 27 28 29 30 31

2012-07-01

Re: MemSQL the "world's fastest database"? Greg Smith (04:18)
Re: SSD, Postgres and safe write cache Greg Smith (04:37)
Re: MemSQL the "world's fastest database"? Scott Marlowe (05:00)

2012-07-03

static virtual columns as result? PV (09:29)
Re: static virtual columns as result? Kevin Grittner (13:44)
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. Stanislaw Pankevich (15:22)
Re: static virtual columns as result? PV (15:43)
Re: Drop statistics? Bruce Momjian (17:16)
Re: MemSQL the "world's fastest database"? Gregg Jaskiewicz (21:46)
Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri (23:08)
The need for clustered indexes to boost TPC-V performance Reza Taheri (23:13)

2012-07-04

Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Craig Ringer (05:19)
Re: The need for clustered indexes to boost TPC-V performance Craig Ringer (05:43)
Re: The need for clustered indexes to boost TPC-V performance Thomas Kellerer (07:57)
Re: The need for clustered indexes to boost TPC-V performance Craig Ringer (08:31)
Re: static virtual columns as result? PV (10:35)
Paged Query Hermann Matthes (12:25)
Re: The need for clustered indexes to boost TPC-V performance Daniel Farina (13:39)
Re: The need for clustered indexes to boost TPC-V performance Claudio Freire (14:26)
Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri (18:24)
Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Mark Kirkwood (22:35)

2012-07-05

Re: Drop statistics? David Kerr (05:53)
Re: The need for clustered indexes to boost TPC-V performance Robert Klemme (12:30)
Re: The need for clustered indexes to boost TPC-V performance Reza Taheri (19:10)
Re: The need for clustered indexes to boost TPC-V performance Reza Taheri (19:13)
Re: The need for clustered indexes to boost TPC-V performance Samuel Gendler (19:46)
Re: The need for clustered indexes to boost TPC-V performance Reza Taheri (20:37)
Re: The need for clustered indexes to boost TPC-V performance Samuel Gendler (20:52)

2012-07-06

Re: The need for clustered indexes to boost TPC-V performance Andy Colson (00:41)
Re: The need for clustered indexes to boost TPC-V performance Craig Ringer (00:46)
SSDs again, LSI Warpdrive 2 anyone? Mark Kirkwood (00:51)
Re: The need for clustered indexes to boost TPC-V performance Craig Ringer (00:57)
Re: The need for clustered indexes to boost TPC-V performance Reza Taheri (01:00)
Re: The need for clustered indexes to boost TPC-V performance Craig Ringer (01:04)
Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Greg Smith (01:25)
Re: The need for clustered indexes to boost TPC-V performance Greg Smith (01:42)
Re: MemSQL the "world's fastest database"? Greg Smith (01:45)
What would effect planning time? David Kerr (02:12)
Re: [PERFORM] The need for clustered indexes to boost TPC-V performance Craig Ringer (03:02)
Re: The need for clustered indexes to boost TPC-V performance Craig Ringer (03:08)
Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri (03:22)
Re: The need for clustered indexes to boost TPC-V performance Reza Taheri (03:33)
Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Craig Ringer (03:41)
The overall experience of TPC-V benchmark team with PostgreSQL Reza Taheri (03:56)
Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri (04:03)
Re: SSDs again, LSI Warpdrive 2 anyone? Mark Kirkwood (04:08)
Re: The need for clustered indexes to boost TPC-V performance Reza Taheri (04:19)
select operations that generate disk writes CSS (06:10)
how could select id=xx so slow? Yan Chunlu (06:17)
Re: select operations that generate disk writes Pavel Stehule (06:20)
Re: select operations that generate disk writes Craig Ringer (06:52)
Re: how could select id=xx so slow? Daniel Farina (09:46)
Re: how could select id=xx so slow? Craig Ringer (11:16)
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. Craig Ringer (11:29)
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. Craig Ringer (11:35)
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. Daniel Farina (11:38)
Re: how could select id=xx so slow? Albe Laurenz (13:10)
Re: Paged Query Віталій Тимчишин (13:18)
Re: Paged Query Albe Laurenz (13:19)
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. Stanislaw Pankevich (13:25)
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. Stanislaw Pankevich (13:30)
Re: Paged Query Greg Spiegelberg (13:35)
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. Craig Ringer (13:38)
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. Albe Laurenz (13:39)
Re: Paged Query Misa Simic (13:43)
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. Stanislaw Pankevich (13:45)
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. Stanislaw Pankevich (13:51)
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. Andres Freund (14:14)
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. Craig Ringer (14:22)
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. Albe Laurenz (14:46)
Create tables performance Sylvain CAILLET (15:15)
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. Marc Mamin (15:24)
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. Stanislaw Pankevich (15:27)
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. Stanislaw Pankevich (15:44)
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. Jeff Janes (15:57)
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. Steve Crawford (16:06)
Re: Create tables performance Jeff Janes (17:22)
Re: Create tables performance Richard Huxton (18:12)
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. Chris Hanks (18:32)

2012-07-07

Re: Create tables performance Craig Ringer (02:27)
Terrible plan for join to nested union Nate Allan (22:35)

2012-07-08

Re: Terrible plan for join to nested union Tom Lane (00:08)
Re: Terrible plan for join to nested union Nate Allan (05:50)
Re: Terrible plan for join to nested union Pavel Stehule (06:03)
Re: Terrible plan for join to nested union Nate Allan (09:43)
Re: Terrible plan for join to nested union Tom Lane (15:56)

2012-07-09

Re: Terrible plan for join to nested union Nate Allan (04:02)
Re: Terrible plan for join to nested union Tom Lane (05:49)
Re: Terrible plan for join to nested union Nate Allan (06:20)
Re: Create tables performance Sylvain CAILLET (06:49)
Re: how could select id=xx so slow? Yan Chunlu (09:20)
Re: Paged Query Gregg Jaskiewicz (11:55)
Re: Paged Query Craig Ringer (12:02)
Re: Paged Query Shaun Thomas (13:22)
Re: Paged Query Craig James (14:16)
Re: Paged Query Greg Spiegelberg (14:33)
Re: Create tables performance Jeff Janes (17:02)
Re: SSDs again, LSI Warpdrive 2 anyone? jamonb (17:16)
Re: Paged Query Misa Simic (17:41)
Re: Paged Query Andrew Dunstan (17:46)
Re: Paged Query Gurjeet Singh (18:13)
Re: Paged Query Misa Simic (22:24)
Re: Paged Query Craig Ringer (23:48)
Re: Paged Query Craig Ringer (23:50)

2012-07-10

Re: Paged Query Jeff Janes (00:34)
Re: how could select id=xx so slow? Craig Ringer (01:25)
Re: how could select id=xx so slow? Yan Chunlu (02:25)
Re: how could select id=xx so slow? Craig Ringer (02:46)
Re: how could select id=xx so slow? Yan Chunlu (02:58)
Massive I/O spikes during checkpoint David Kerr (05:39)
Re: Massive I/O spikes during checkpoint Maxim Boguk (05:51)
Re: Massive I/O spikes during checkpoint Jeff Janes (05:52)
Re: Massive I/O spikes during checkpoint David Kerr (05:59)
Re: Massive I/O spikes during checkpoint David Kerr (06:03)
Re: Massive I/O spikes during checkpoint Maxim Boguk (06:14)
Re: Massive I/O spikes during checkpoint David Kerr (06:17)
Re: Create tables performance Sylvain CAILLET (06:27)
Any tool/script available which can be used to measure scalability of an application's database. Sreejith Balakrishnan (08:21)
Custom function in where clause Pena Kupen (08:36)
Re: Custom function in where clause Maxim Boguk (08:44)
Re: Custom function in where clause Brendan Jurd (08:45)
Re: Custom function in where clause Pena Kupen (09:30)
Fw: Re: Custom function in where clause Pena Kupen (10:20)
Re: Massive I/O spikes during checkpoint Andres Freund (12:44)
Re: Massive I/O spikes during checkpoint Jeff Janes (13:36)
Re: Massive I/O spikes during checkpoint Andres Freund (13:41)
Re: The need for clustered indexes to boost TPC-V performance Merlin Moncure (19:05)
Re: The need for clustered indexes to boost TPC-V performance Reza Taheri (19:35)

2012-07-11

DELETE vs TRUNCATE explanation Craig Ringer (00:37)
Re: DELETE vs TRUNCATE explanation Daniel Farina (05:22)
Re: how could select id=xx so slow? Yan Chunlu (06:24)
Re: Paged Query Віталій Тимчишин (08:15)
Re: Paged Query Віталій Тимчишин (08:23)
Re: how could select id=xx so slow? Albe Laurenz (08:23)
Re: how could select id=xx so slow? Yan Chunlu (11:40)
query overhead Andy Halsall (11:46)
Re: how could select id=xx so slow? Ants Aasma (11:59)
Re: DELETE vs TRUNCATE explanation Tom Lane (14:05)
Re: DELETE vs TRUNCATE explanation ktm@rice.edu (14:19)
Re: how could select id=xx so slow? Yan Chunlu (16:35)
Re: moving tables Midge Brown (17:25)
Re: DELETE vs TRUNCATE explanation Matthew Woodcraft (18:10)
Re: DELETE vs TRUNCATE explanation Craig James (20:18)
Re: DELETE vs TRUNCATE explanation Shaun Thomas (20:47)
Re: DELETE vs TRUNCATE explanation Andrew Dunstan (21:04)
Re: DELETE vs TRUNCATE explanation Mark Thornton (21:32)
Re: DELETE vs TRUNCATE explanation Craig James (22:09)
Re: DELETE vs TRUNCATE explanation Daniel Farina (22:51)

2012-07-12

PostgreSQL index issue codevally (00:03)
Re: how could select id=xx so slow? Craig Ringer (00:18)
Re: how could select id=xx so slow? Yan Chunlu (00:47)
Re: how could select id=xx so slow? Maciek Sakrejda (01:07)
Re: DELETE vs TRUNCATE explanation Craig Ringer (01:23)
Re: DELETE vs TRUNCATE explanation Craig Ringer (01:26)
Re: DELETE vs TRUNCATE explanation Craig Ringer (01:41)
Re: how could select id=xx so slow? Craig Ringer (02:20)
Re: how could select id=xx so slow? Yan Chunlu (05:10)
Re: DELETE vs TRUNCATE explanation Daniel Farina (06:12)
Re: how could select id=xx so slow? Craig Ringer (06:56)
Re: DELETE vs TRUNCATE explanation Craig Ringer (07:45)
Re: how could select id=xx so slow? Yan Chunlu (12:48)
Re: how could select id=xx so slow? Craig Ringer (14:39)
Re: how could select id=xx so slow? Ants Aasma (16:07)
Re: how could select id=xx so slow? Jeff Janes (18:53)
Re: DELETE vs TRUNCATE explanation Jeff Janes (19:15)
Re: DELETE vs TRUNCATE explanation Harold A. Giménez (23:21)

2012-07-13

Re: DELETE vs TRUNCATE explanation Jeff Janes (01:00)
Re: how could select id=xx so slow? Yan Chunlu (04:02)
Re: [PERFORM] DELETE vs TRUNCATE explanation Jeff Janes (04:55)
slow prepare, lots of semop calls. David Kerr (06:51)
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. Stanislaw Pankevich (07:50)
Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Eoghan Murray (14:11)
Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Claudio Freire (15:53)
Re: query overhead Tom Lane (16:15)
Is there a tool available to perform Data Model review, from a performance perspective? B Sreejith (16:25)
Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Claudio Freire (16:40)
Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Tom Lane (17:40)
Re: Any tool/script available which can be used to measure scalability of an application's database. Sergey Konoplev (18:37)
Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Claudio Freire (18:56)
Re: Any tool/script available which can be used to measure scalability of an application's database. Robert Klemme (20:06)

2012-07-14

Re: Any tool/script available which can be used to measure scalability of an application's database. B Sreejith (01:21)
Re: Any tool/script available which can be used to measure scalability of an application's database. B Sreejith (01:26)
Re: query overhead Craig Ringer (03:28)
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. Craig Ringer (03:35)
Re: Any tool/script available which can be used to measure scalability of an application's database. Craig Ringer (05:05)
Re: Any tool/script available which can be used to measure scalability of an application's database. Craig Ringer (08:48)
Re: Any tool/script available which can be used to measure scalability of an application's database. John Jones (09:10)
Re: Any tool/script available which can be used to measure scalability of an application's database. B Sreejith (09:50)
Re: Any tool/script available which can be used to measure scalability of an application's database. Robert Klemme (12:17)
Re: Any tool/script available which can be used to measure scalability of an application's database. Sergey Konoplev (12:49)
Re: Any tool/script available which can be used to measure scalability of an application's database. Craig Ringer (15:10)

2012-07-15

Re: [PERFORM] DELETE vs TRUNCATE explanation Jeff Janes (00:10)
Index slow down insertions... Ioannis Anagnostopoulos (01:14)
Re: [PERFORM] DELETE vs TRUNCATE explanation Tom Lane (18:29)
Re: [PERFORM] DELETE vs TRUNCATE explanation Tom Lane (22:37)

2012-07-16

Re: [PERFORM] DELETE vs TRUNCATE explanation Craig Ringer (00:22)
Re: [PERFORM] DELETE vs TRUNCATE explanation Tom Lane (01:37)
Re: [PERFORM] DELETE vs TRUNCATE explanation Craig Ringer (01:43)
Proposed change for 9.3(?): Require full restart to change fsync parameter, not just pg_ctl reload Craig Ringer (01:54)
Re: PostgreSQL index issue Albe Laurenz (07:44)

Prev | Next

Jump to day: 1 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 23 24 25 26 27 28 29 30 31

Privacy Policy | About PostgreSQL
Copyright © 1996-2013 The PostgreSQL Global Development Group