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 - June 2003

Prev | Next

Jump to day: 1 2 5 6 9 10 11 12 13 14 15 16 17 18 20 23 24 25 26 27 28 30

2003-06-01

Re: Index speeds up one row table (why)? Rod Taylor (02:29)
are views typically any faster/slower than equivilent joins? Brian Tarbox (02:55)
Re: are views typically any faster/slower than equivilent joins? Rod Taylor (04:02)
Re: are views typically any faster/slower than equivilent joins? Rod Taylor (04:05)
Re: Index speeds up one row table (why)? Bruno Wolff III (05:33)
Re: are views typically any faster/slower than equivilent joins? Bruno Wolff III (05:43)
Re: Index speeds up one row table (why)? Dave E Martin XXIII (07:20)
Re: are views typically any faster/slower than Rod Taylor (11:56)
Re: Index speeds up one row table (why)? Rod Taylor (12:14)
Re: Index speeds up one row table (why)? Bruno Wolff III (19:04)

2003-06-02

Select Query Performance Ricky Prasla (01:12)
Re: Select Query Performance Rod Taylor (01:48)
FW: Query Plan problem George Papastamatopoulos (04:56)
Re: FW: Query Plan problem Tom Lane (05:31)
Degrading performance Mindaugas Riauba (05:33)
Re: FW: Query Plan problem Paul Smith (05:35)
Re: Index speeds up one row table (why)? Dave E Martin XXIII (07:14)
Re: Index speeds up one row table (why)? Peter Childs (07:51)
Re: Degrading performance Tom Lane (13:36)
Re: Enabling and Disabling Sequencial Scan scott.marlowe (15:20)
Re: Enabling and Disabling Sequencial Scan scott.marlowe (15:23)
Re: Degrading performance scott.marlowe (16:34)
Re: Degrading performance Tom Lane (17:25)
Re: Degrading performance scott.marlowe (17:42)

2003-06-05

Enabling and disabling run time configuration parameters. Yusuf (15:35)
Re: Enabling and disabling run time configuration parameters. Rod Taylor (16:14)
Re: Enabling and disabling run time configuration parameters. Bruno Wolff III (16:15)
Re: Enabling and disabling run time configuration parameters. Josh Berkus (16:19)
Re: Enabling and disabling run time configuration parameters. Andrew Sullivan (16:39)
Re: Enabling and disabling run time configuration parameters. scott.marlowe (16:42)

2003-06-06

[Fwd: Re: Enabling and disabling run time configuration parameters.] Yusuf (18:53)

2003-06-09

FW: [ADMIN] Shared_buffers and kernel parameters, tuning Howard Oblowitz (09:18)
Hash or merge join instead of inner loop Jim C. Nasby (20:40)

2003-06-10

Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Shridhar Daithankar (05:15)
Re: Hash or merge join instead of inner loop Tom Lane (06:15)
Re: Hash or merge join instead of inner loop Shridhar Daithankar (08:56)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Josh Berkus (15:46)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Shridhar Daithankar (15:56)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Josh Berkus (16:03)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Bruno Wolff III (17:21)
Re-ordering .CONF params ... questions for this list Josh Berkus (18:01)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Vincent van Leeuwen (18:12)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Josh Berkus (18:28)
Re: Re-ordering .CONF params ... questions for this list Richard Huxton (19:05)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Bruce Momjian (19:08)
Re: Hash or merge join instead of inner loop Jim C. Nasby (19:42)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Tom Lane (19:43)
Re: Re-ordering .CONF params ... questions for this list Joe Conway (20:05)
Re: Hash or merge join instead of inner loop Tom Lane (20:56)
Re: Re-ordering .CONF params ... questions for this list Josh Berkus (20:57)
Re: Re-ordering .CONF params ... questions for this list Tom Lane (21:28)
Re: Re-ordering .CONF params ... questions for this list Josh Berkus (21:29)
Re: Re-ordering .CONF params ... questions for this list Josh Berkus (21:45)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Vincent van Leeuwen (23:10)
Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Vincent van Leeuwen (23:25)

2003-06-11

Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning Bruce Momjian (03:52)
left join performance problem pginfo (15:35)
tweaking costs to favor nestloop Vincent van Leeuwen (19:33)
Re: tweaking costs to favor nestloop Tom Lane (20:17)

2003-06-12

Re: left join performance problem Tom Lane (02:57)
Re: left join performance problem pginfo (04:48)
Re: Table Relationships Andreas Kostyrka (09:32)
new monster box CONF suggestion please Patrick Hatcher (16:33)

2003-06-13

Adjusting fsm values was Re: [BUGS] db growing out of proportion Robert Creager (03:49)
Re: db growing out of proportion Tomas Szepe (05:34)
Re: tweaking costs to favor nestloop Vincent van Leeuwen (12:39)
Re: tweaking costs to favor nestloop Tom Lane (14:07)
7.3 vs 7.2 - different query plan, bad performance Ryszard Lach (18:45)
Re: 7.3 vs 7.2 - different query plan, bad performance Bruno Wolff III (18:54)
Re: Re-ordering .CONF params ... questions for this list Nick Fankhauser (22:31)
Re: Re-ordering .CONF params ... questions for this list Josh Berkus (22:51)

2003-06-14

A bit OT- RE: [PERFORM] Re-ordering .CONF params ... questions for this list Nick Fankhauser (14:40)

2003-06-15

any way to use indexscan to get last X values with "order by Y limit X" clause? Tomaz Borstnar (14:26)
Re: any way to use indexscan to get last X values with "order by Y limit X" clause? Shridhar Daithankar (14:31)
Re: any way to use indexscan to get last X values Tomaz Borstnar (15:17)
Re: any way to use indexscan to get last X values with Stephan Szabo (16:33)
Re: any way to use indexscan to get last X values with "order by Y limit X" clause? Tom Lane (16:53)
Re: 7.3 vs 7.2 - different query plan, bad performance Manfred Koizar (19:48)
Re: any way to use indexscan to get last X values Tomaz Borstnar (22:37)
Re: any way to use indexscan to get last X values Tomaz Borstnar (23:21)

2003-06-16

Re: left join performance problem Jim C. Nasby (05:10)
Re: tweaking costs to favor nestloop Jim C. Nasby (05:17)
Re: left join performance problem Tom Lane (05:28)
Partial index where clause not filtering through Jim C. Nasby (05:31)
Re: left join performance problem Jim C. Nasby (05:36)
Re: Partial index where clause not filtering through Tom Lane (05:43)
Re: any way to use indexscan to get last X values Shridhar Daithankar (06:15)
Re: Partial index where clause not filtering through Jim C. Nasby (06:24)
Re: 7.3 vs 7.2 - different query plan, bad performance siaco (06:38)
Re: any way to use indexscan to get last X values Tomaz Borstnar (07:08)
Re: any way to use indexscan to get last X values Shridhar Daithankar (07:22)
Re: left join performance problem Bruno Wolff III (08:07)
Postgres Connections Requiring Large Amounts of Memory Dawn Hollingsworth (08:32)
Re: Postgres Connections Requiring Large Amounts of Memory Dawn Hollingsworth (08:57)
Re: 7.3 vs 7.2 - different query plan, bad performance Manfred Koizar (10:31)
Re: 7.3 vs 7.2 - different query plan, bad performance Ryszard Lach (11:41)
Re: 7.3 vs 7.2 - different query plan, bad performance Manfred Koizar (13:24)
Re: left join performance problem Tom Lane (13:26)
Re: 7.3 vs 7.2 - different query plan, bad performance Ryszard Lach (13:55)
Re: Partial index where clause not filtering through Tom Lane (14:11)
Re: 7.3 vs 7.2 - different query plan, bad performance Tom Lane (14:17)
Re: A bit OT- RE: [PERFORM] Re-ordering .CONF params ... questions for this list Josh Berkus (16:28)
functional indexes instead of regular index on field(s)? Tomaz Borstnar (17:38)
Re: functional indexes instead of regular index on field(s)? Bruno Wolff III (17:58)
sequential scans on few columns tables Tomasz Myrta (19:49)
Re: sequential scans on few columns tables Bruno Wolff III (19:55)
Re: sequential scans on few columns tables Tomasz Myrta (20:32)
Re: Postgres Connections Requiring Large Amounts of Memory Tom Lane (20:45)
Re: Postgres Connections Requiring Large Amounts of Memory Tom Lane (21:34)
Re: Partial index where clause not filtering through Jim C. Nasby (22:32)
Re: Partial index where clause not filtering through Tom Lane (22:39)
Re: left join performance problem Jim C. Nasby (22:41)
Re: sequential scans on few columns tables Jim C. Nasby (22:45)
Interesting incosistent query timing Ernest E Vogelsinger (22:46)
Re: Interesting incosistent query timing Manfred Koizar (23:45)

2003-06-17

Re: [PERFORM] Interesting incosistent query timing Nikolaus Dilger (02:20)
Re: [PERFORM] Interesting incosistent query timing Ernest E Vogelsinger (02:54)
Re: Postgres Connections Requiring Large Amounts of Memory Dawn Hollingsworth (06:46)
approve xec5mm unsubscribe pgsql-performance jgimenez@sipec.es Jordi Giménez (07:43)
Re: Postgres Connections Requiring Large Amounts of Memory Dawn Hollingsworth (09:42)
Limiting Postgres memory usage Howard Oblowitz (09:53)
Re: Limiting Postgres memory usage Shridhar Daithankar (10:25)
Re: Postgres Connections Requiring Large Amounts of Memory Dawn Hollingsworth (11:03)
Re: Postgres Connections Requiring Large Amounts of Memory Tom Lane (19:38)
Re: Postgres Connections Requiring Large Amounts of Memory Tom Lane (22:03)
Re: [PERFORM] Interesting incosistent query timing nikolaus (22:45)
Re: [PERFORM] Interesting incosistent query timing Ernest E Vogelsinger (23:01)
Re: Postgres Connections Requiring Large Amounts of Memory Tom Lane (23:21)

2003-06-18

Re: [PERFORM] Interesting incosistent query timing Tom Lane (00:12)
Re: Postgres Connections Requiring Large Amounts of Memory SZŰCS Gábor (07:11)
Recent 7.4 change slowed down a query by a factor of 3 Bruno Wolff III (15:02)
Re: Recent 7.4 change slowed down a query by a factor of 3 Tom Lane (15:18)
Re: Recent 7.4 change slowed down a query by a factor of 3 Bruno Wolff III (15:43)
Re: Recent 7.4 change slowed down a query by a factor of 3 Bruno Wolff III (15:45)
Re: Recent 7.4 change slowed down a query by a factor of 3 Bruno Wolff III (15:53)
Re: Recent 7.4 change slowed down a query by a factor of 3 Tom Lane (16:21)

2003-06-20

Deleting one record from a table taking 17s. Yusuf (15:53)
Re: Deleting one record from a table taking 17s. Rod Taylor (16:06)
Re: Deleting one record from a table taking 17s. Tom Lane (16:59)
Re: Deleting one record from a table taking 17s. Yusuf (17:06)
Re: Deleting one record from a table taking 17s. Rod Taylor (22:04)

2003-06-23

Unsubscribe Howard Oblowitz (06:40)

2003-06-24

Performance advice Michael Mattox (07:39)
Re: Performance advice Shridhar Daithankar (07:59)
Re: Performance advice Shridhar Daithankar (08:19)
Re: Performance advice Shridhar Daithankar (09:02)
Re: Performance advice Richard Huxton (11:33)
Re: Performance advice Michael Mattox (12:16)
Re: Performance advice Achilleus Mantzios (14:10)
Re: Performance advice Tom Lane (14:18)
Re: Performance advice Michael Mattox (15:47)
Re: Performance advice Josh Berkus (16:04)
Re: Performance advice Rod Taylor (17:00)

2003-06-25

Re: Performance advice Michael Mattox (06:48)
Re: Performance advice Manfred Koizar (06:51)
Re: Performance advice Hilary Forbes (08:12)
Re: Performance advice Howard Oblowitz (08:58)
Re: Performance advice Michael Mattox (09:47)
Re: Performance advice Shridhar Daithankar (09:58)
Re: Performance advice Rod Taylor (11:06)
Re: Performance advice Rod Taylor (11:09)
How to optimize monstrous query, sorts instead of using index Michael Mattox (11:46)
Re: Performance advice Paul Thomas (11:52)
Re: How to optimize monstrous query, sorts instead of using index Rod Taylor (11:54)
Re: How to optimize monstrous query, sorts instead of using index Michael Mattox (12:00)
Re: How to optimize monstrous query, sorts instead of Rod Taylor (12:12)
Re: How to optimize monstrous query, sorts instead of Michael Mattox (12:48)
Re: Performance advice pgsql (13:04)
Re: How to optimize monstrous query, sorts instead of Rod Taylor (13:36)
Re: How to optimize monstrous query, sorts instead of Michael Mattox (14:09)
Re: How to optimize monstrous query, sorts instead of using index SZUCS Gábor (14:15)
Re: How to optimize monstrous query, sorts instead of SZUCS Gábor (14:20)
Re: How to optimize monstrous query, sorts instead of Rod Taylor (14:28)
Re: How to optimize monstrous query, sorts instead of using index Michael Mattox (14:48)
Re: How to optimize monstrous query, sorts instead of Michael Mattox (15:09)
Re: How to optimize monstrous query, sorts instead of Tom Lane (15:55)
Re: Performance advice Achilleus Mantzios (16:32)
Re: How to optimize monstrous query, sorts instead of using index Tom Lane (16:39)
Similar querys, better execution time on worst execution plan Fernando Papa (19:25)
Query running slower than same on Oracle Sailer, Denis (YBUSA-CDR) (21:33)
Re: Query running slower than same on Oracle Tom Lane (21:50)
Re: Query running slower than same on Oracle Josh Berkus (21:51)

2003-06-26

Re: Similar querys, better execution time on worst execution plan SZUCS Gábor (10:30)
Re: Performance advice Manfred Koizar (12:49)
problem with pg_statistics Andre Schubert (13:15)
Re: Similar querys, better execution time on worst execution plan Fernando Papa (13:33)
Re: problem with pg_statistics Tom Lane (14:08)
Re: Similar querys, better execution time on worst execution plan SZUCS Gábor (15:06)
Re: problem with pg_statistics Manfred Koizar (15:51)
Re: problem with pg_statistics Tom Lane (16:03)

2003-06-27

Re: problem with pg_statistics Andre Schubert (06:07)
Re: problem with pg_statistics Andre Schubert (06:13)
Re: problem with pg_statistics Manfred Koizar (08:43)
Re: problem with pg_statistics Andre Schubert (09:10)
Re: problem with pg_statistics Manfred Koizar (10:05)
Large querie with several EXISTS which will be often runned Bruno BAGUETTE (14:32)
Re: Large querie with several EXISTS which will be often runned Josh Berkus (15:41)
Memory question Patrick Hatcher (19:09)
Re: Memory question scott.marlowe (19:44)
Re: Memory question Josh Berkus (19:54)

Prev | Next

Jump to day: 1 2 5 6 9 10 11 12 13 14 15 16 17 18 20 23 24 25 26 27 28 30

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