• Text Size: Normal / Large
• Donate
• Contact

Section Navigation

• Community
• Contributors
• Mailing Lists
  • Subscribe
  • User lists
    • pgsql-admin
    • pgsql-advocacy
    • pgsql-announce
    • pgsql-bugs
    • pgsql-docs
    • pgsql-cygwin
    • pgsql-general
    • pgsql-interfaces
    • pgsql-jdbc
    • pgsql-jobs
    • pgsql-novice
    • pgsql-odbc
    • pgsql -performance
    • pgsql-php
    • pgsql-ports
    • pgsql-sql
  • Developer lists
  • Regional lists
  • Project lists
  • User groups
  • Inactive lists
• IRC
• Featured Users
• International Sites
• Propaganda
• Resources
• Weekly News
• Community login
  • Profile
  • Lost password

pgsql-performance 2007-01 Chronological Index (2/3)

• Thread Index
• [Prev Page]
• [Next Page]

• 17 January 2007
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: PG8.2.1 choosing slow seqscan over idx scan Tomas Vondra
  • Re: PG8.2.1 choosing slow seqscan over idx scan Tomas Vondra
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: PG8.2.1 choosing slow seqscan over idx scan Scott Marlowe
  • Re: Monitoring Transaction Log size Stefan Kaltenbrunner
  • Re: Monitoring Transaction Log size Shoaib Mir
  • Re: Monitoring Transaction Log size Joshua D. Drake
  • Monitoring Transaction Log size Ziegelwanger, Silvio
  • Re: PG8.2.1 choosing slow seqscan over idx scan Chad Wagner
  • Re: [HACKERS] unusual performance for vac following 8.2 Kim
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: PG8.2.1 choosing slow seqscan over idx scan Scott Marlowe
  • Raid 10 or Raid 5 on Dell PowerEdge Dave Dutcher
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: PG8.2.1 choosing slow seqscan over idx scan Dave Cramer
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: PG8.2.1 choosing slow seqscan over idx scan Shoaib Mir
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: Table Inheritence and Partioning Albert Cervera Areny
  • Table Inheritence and Partioning ramachandra.bhaskaram
  • Re: Table Size Guillaume Lelarge
  • Re: PG8.2.1 choosing slow seqscan over idx scan Scott Marlowe
  • Re: PG8.2.1 choosing slow seqscan over idx scan Chad Wagner
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
• 16 January 2007
  • Re: PG8.2.1 choosing slow seqscan over idx scan Chad Wagner
  • Re: PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: PG8.2.1 choosing slow seqscan over idx scan Tom Lane
  • PG8.2.1 choosing slow seqscan over idx scan Jeremy Haile
  • Re: Table Size Richard Huxton
  • Re: Caching in PostgreSQL Chris Browne
  • Table Size Gauri Kanekar
  • Re: Caching in PostgreSQL David Levy
  • Re: Caching in PostgreSQL Heikki Linnakangas
  • Re: Caching in PostgreSQL ramachandra.bhaskaram
  • Re: Caching in PostgreSQL Heikki Linnakangas
  • Caching in PostgreSQL ramachandra.bhaskaram
• 15 January 2007
  • FiberChannel cards for FreeBSD on AMD64 Andrew Hammond
  • Re: max() versus order/limit (WAS: High update Joshua D. Drake
  • Re: pg_trgm performance Steinar H. Gunderson
  • Re: max() versus order/limit (WAS: High update Alvaro Herrera
  • Re: max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS) Alvaro Herrera
  • pg_trgm performance Florian Weimer
  • Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?) HA/EXA
  • Re: max() versus order/limit (WAS: High update Luke Lonergan
  • Re: max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS) Adam Rich
• 14 January 2007
  • Re: Large table performance Luke Lonergan
  • Re: Large table performance Luke Lonergan
  • Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?) Dave Cramer
  • Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?) Dave Dutcher
  • Re: Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?) HA/EXA
  • Re: Dave Cramer
  • Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?) HA/EXA
  • [no subject] HA/EXA
  • Re: Large table performance Shoaib Mir
  • Re: Performance of Parser? Dave Cramer
  • Re: Large table performance Dave Dutcher
  • Re: Performance of Parser? Tom Lane
• 13 January 2007
  • Performance of Parser? Jignesh Shah
  • Re: Large table performance Daniel Cristian Cruz
  • Physical separation of tables and indexes - where pg_xlog should go? Ireneusz Pluta
  • Re: Large table performance Steinar H. Gunderson
  • Re: Large table performance Dave Cramer
  • Large table performance Mark Dobbrow
• 12 January 2007
  • Re: [HACKERS] table partioning performance Simon Riggs
  • RES: Improving SQL performance Carlos H. Reimer
  • Partitioning Gauri Kanekar
  • Re: Planner statistics, correlations Heikki Linnakangas
  • Re: Planner statistics, correlations Tobias Brox
  • Re: Planner statistics, correlations Heikki Linnakangas
  • Re: Planner statistics, correlations Tobias Brox
  • Re: Planner statistics, correlations Richard Huxton
  • Re: [HACKERS] unusual performance for vac following 8.2upgrade Richard Huxton
  • Re: Planner statistics, correlations Tobias Brox
  • Re: Planner statistics, correlations Peter Childs
  • Planner statistics, correlations Tobias Brox
  • Re: [HACKERS] unusual performance for vac following 8.2upgrade Tom Lane
  • Re: [HACKERS] unusual performance for vac following 8.2upgrade Alvaro Herrera
• 11 January 2007
  • Re: RES: Improving SQL performance Cesar Suga
  • Re: [HACKERS] unusual performance for vac following 8.2upgrade Simon Riggs
  • Re: unusual performance for vac following 8.2 upgrade Kim
  • Re: [HACKERS] unusual performance for vac following 8.2 upgrade Tom Lane
  • Re: unusual performance for vac following 8.2 upgrade Tom Lane
  • Re: unusual performance for vac following 8.2 upgrade Kim
  • Re: [HACKERS] unusual performance for vac following 8.2 upgrade Jim C. Nasby
  • RES: Improving SQL performance Carlos H. Reimer
  • Re: [HACKERS] unusual performance for vac following 8.2 upgrade Tom Lane
  • Re: [HACKERS] table partioning performance Jim C. Nasby
  • Re: unusual performance for vac following 8.2 upgrade Simon Riggs
  • Re: [HACKERS] unusual performance for vac following 8.2 upgrade Alvaro Herrera
  • Re: unusual performance for vac following 8.2 upgrade Tom Lane
  • Re: unusual performance for vac following 8.2 upgrade Kim
  • Re: Improving SQL performance Tom Lane
  • Re: Improving SQL performance Russell Smith
  • Re: unusual performance for vac following 8.2 upgrade Tom Lane
  • Re: unusual performance for vac following 8.2 upgrade Tom Lane
  • Improving SQL performance Carlos H. Reimer
  • Re: unusual performance for vac following 8.2 upgrade Russell Smith
  • unusual performance for vac following 8.2 upgrade Kim
  • Re: Partitioning Bernd Helmle
  • Re: Partitioning Adam Rich
  • Re: Partitioning Jeremy Haile
  • Re: Partitioning Mikael Carneholm
  • Re: Partitioning Bernd Helmle
  • Re: table partioning performance Simon Riggs
  • Re: Does it matters the column order in indexes and constraints Richard Huxton
  • Does it matters the column order in indexes and constraints creation? Arnau
  • Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Jim C. Nasby
  • Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Alvaro Herrera
  • Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Jim C. Nasby
  • Re: table partioning performance Jim C. Nasby
  • UNSUBSCRIBE andrew
• 10 January 2007
  • Re: High inserts, bulk deletes - autovacuum vs scheduled Jeremy Haile
  • Re: Partitioning Scott Marlowe
  • Re: table partioning performance Steven Flatt
  • Re: Partitioning Jeremy Haile
  • Re: Partitioning Scott Marlowe
  • Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Jim C. Nasby
  • Re: Partitioning Jim C. Nasby
  • Re: table partioning performance Steven Flatt
  • Re: Performance of PostgreSQL on Windows vs Linux Scott Marlowe
  • Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Jim C. Nasby
  • Re: Performance of PostgreSQL on Windows vs Linux Jeremy Haile
  • Re: High update activity, PostgreSQL vs BigDBMS Jeff Frost
  • Re: Partitioning Jeremy Haile
  • Re: Partitioning Erik Jones
  • Re: High update activity, PostgreSQL vs BigDBMS Jim C. Nasby
  • Re: table partioning performance Jim C. Nasby
  • Re: Partitioning Jim C. Nasby
  • Re: PostgreSQL to host e-mail? Jim C. Nasby
  • Re: Performance of PostgreSQL on Windows vs Linux Jim C. Nasby
  • Re: More 8.2 client issues (Was: [Slow dump?) Jim C. Nasby
  • Re: performance implications of binary placement Jim C. Nasby
  • Re: Slow inner join, but left join is fast Jeremy Haile
  • Re: Slow inner join, but left join is fast Tom Lane
  • Re: Slow inner join, but left join is fast Jeremy Haile
  • Re: Slow inner join, but left join is fast Jeremy Haile
  • Re: Slow inner join, but left join is fast Tom Lane
  • Re: Slow inner join, but left join is fast Jeremy Haile
  • Re: Slow inner join, but left join is fast Tom Lane
  • Re: group by will not use an index? tsuraan
  • Slow inner join, but left join is fast Jeremy Haile
  • Re: Horribly slow query/ sequential scan Tom Lane
  • Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Florian Weimer
  • Re: Horribly slow query/ sequential scan Tom Lane
  • Re: group by will not use an index? Andrew Lazarus
  • Re: group by will not use an index? Steinar H. Gunderson
  • Re: group by will not use an index? Brian Herlihy
• 09 January 2007
  • Re: group by will not use an index? Scott Marlowe
  • Re: Horribly slow query/ sequential scan Gregory S. Williamson
  • Re: group by will not use an index? Adam Rich
  • group by will not use an index? tsuraan
  • Re: High inserts, bulk deletes - autovacuum vs scheduled Jeremy Haile
  • Re: High inserts, bulk deletes - autovacuum vs scheduled vacuum Florian Weimer
  • High inserts, bulk deletes - autovacuum vs scheduled vacuum Jeremy Haile
  • Re: High update activity, PostgreSQL vs BigDBMS Jeff Frost
  • Re: Postgresql Configutation and overflow Jim C. Nasby
  • Re: Horribly slow query/ sequential scan Plugge, Joe R.
  • Re: Horribly slow query/ sequential scan Tom Lane
  • Re: Horribly slow query/ sequential scan Dave Cramer
  • Re: Running PG on cluster files systems Devrim GUNDUZ
  • Re: Worse perfomance on 8.2.0 than on 7.4.14 Rolf Østvik
  • Running PG on cluster files systems Hannes Dorbath
  • Re: Horribly slow query/ sequential scan Gregory S. Williamson
  • Re: Horribly slow query/ sequential scan Nörder-Tuitje , Marcus
  • Re: Horribly slow query/ sequential scan Gregory S. Williamson
  • Re: High update activity, PostgreSQL vs BigDBMS Jim C. Nasby
  • Re: table partioning performance Simon Riggs
  • Re: Horribly slow query/ sequential scan db
  • Re: High update activity, PostgreSQL vs BigDBMS Jim C. Nasby
  • Horribly slow query/ sequential scan Gregory S. Williamson
  • Re: table partioning performance Merlin Moncure
• 08 January 2007
  • Re: table partioning performance Steven Flatt
  • Re: Slow Query on Postgres 8.2 Dave Dutcher
  • Re: High update activity, PostgreSQL vs BigDBMS Bruce Momjian
  • Re: table partioning performance Luke Lonergan
  • Re: tweaking under repeatable load Dimitri Fontaine
  • Re: High update activity, PostgreSQL vs BigDBMS Adam Rich
  • Re: High update activity, PostgreSQL vs BigDBMS Guy Rouillier

• Thread Index
• [Prev Page]
• [Next Page]