PostgreSQL 9.0 & The Future

2,999 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,999
On SlideShare
0
From Embeds
0
Number of Embeds
49
Actions
Shares
0
Downloads
44
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

PostgreSQL 9.0 & The Future

  1. 1. PostgreSQL and the future Aaron Thul
  2. 2. Who am I? •  Computer & Database Geek •  Formerly a Debian SysAdmin •  Presently Vice President of Technology at a EMOL •  PostgreSQL Evangelist •  Penguicon Organizer
  3. 3. Ground rules •  Questions are good •  Arguments are bad
  4. 4. Agenda •  Big News •  New Features •  State of PostgreSQL Community •  Evil •  Profit
  5. 5. First Things First •  There is some big news
  6. 6. First Things First •  There is some big news •  PostgreSQL 8.5 is…
  7. 7. First Things First •  There is some big news •  PostgreSQL 8.5 is… • PostgreSQL 9.0 !
  8. 8. Why 8.5 became 9.0 •  Built-in log-streaming replication •  Hot standby
  9. 9. New Features
  10. 10. Streaming replication •  Warm Standby 8.x to Hot Standby •  New kinds of postmaster processes, walsenders and walreceiver •  Thanks to Streaming Replication, lag should be nearly zero
  11. 11. DROP IF EXISTS •  Columns •  Constraints
  12. 12. Better messages for unique violation •  Improve unique-constraint-violation error messages to include the exact values being complained of.
  13. 13. Deferrable Uniqueness •  Massive unique-key reassignments
  14. 14. MOVE FORWARD or BACKWARD •  MOVE {FORWARD,BACKWARD} X •  More easily move around in a curser
  15. 15. ’samehost’ and ’samenet’ •  Does anyone know what HBA stands for? •  To lazy to list all the hosts on your network •  CIDR-ADDRESS
  16. 16. GRANT ALL •  Grant privileges on all existing tables •  Automatically grant privileges on all tables that will be created in this database in the future
  17. 17. TRIGGERS on columns •  SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list •  Help resolve circular TRIGGER issues
  18. 18. Conditional TRIGGERS CREATE TRIGGER test_u AFTER UPDATE ON test FOR EACH ROW WHEN ( NEW.i <= 0 ) EXECUTE PROCEDURE test_u();
  19. 19. VACUUM FULL •  VACUUM FULL will start to behave like CLUSTER •  Will not actually be reordering rows •  VACUUM FULL INPLACE
  20. 20. Buffers info for explain explain ( analyze on, buffers on ) select count(*) from pg_attribute ; QUERY PLAN ---------------------------------------------------- ---------------------- Aggregate (cost=64.70..64.71 rows=1 width=0) (actual time=0.466..0.466 rows=1 loops=1) Buffers: shared hit=18 read=21 -> Seq Scan on pg_attribute (cost=0.00..59.56 rows=2056 width=0) (actual time=0.002..0.301 rows=2002 loops=1) Buffers: shared hit=18 read=21 Total runtime: 0.492 ms
  21. 21. The list goes on •  Multi-threaded pgbench •  Hinting for number of distinct values •  Machine readable EXPLAIN •  Checking password strength •  PL/pgSQL by default
  22. 22. PostgreSQL Community
  23. 23. Who makes database Software •  Oracle/SUN •  IBM •  Microsoft
  24. 24. PostgreSQL Community •  Community not company •  Growing •  International •  PostgreSQL Association •  Nothing happening with SUN/MySQL/Oracle is hurting the PostgreSQL community
  25. 25. www.postgresql.org •  downloads •  documentation •  bug reports •  security alerts •  wiki •  support companies
  26. 26. www.pgfoundry.org •  Modules •  Programs •  Resources
  27. 27. www.planetpostgresql.org •  Project News •  Community News •  Helpful Tips / Examples
  28. 28. archives.postgresql.org •  mailing list archives back to 1997 •  full text search via postgtresql 8.3 •  keyword search suggestions
  29. 29. #postgresql •  irc.freenode.net •  real time help •  rtfm_please - ??help
  30. 30. PostgreSQL Community Events •  PGCon •  PostgreSQL Conference 2009 Japan •  European PGDay •  PgWest •  PgEast •  PGCon Brazil •  Local PUGs •  http://wiki.postgresql.org/wiki/Events
  31. 31. Project Management •  Core team •  Committers •  -hackers •  Roadmap •  Web team
  32. 32. Threats to PostgreSQL •  Patent attacks •  Hiring of volunteers to work on unrelated projects
  33. 33. Evil
  34. 34. Data Types •  Just use text ▫  char/varchar/text the same under the hood ▫  avoid artificial limits •  Focus on functions ▫  Phone numbers often require string manipulation ▫  Unix timestamp vs. Date arithmetic •  Minimize typecasts
  35. 35. Take advantage of strong data typing •  CHECK limits input at column level •  ENUM limits specific values at type level ▫  Allows you to define a custom order, provides compact storage •  DOMAIN defines a data type within constraint boundaries •  Often outperforms JOIN on lookup tables •  Allows for simpler schema design
  36. 36. Normalization (3NF) •  All non-key columns must be directly dependent on PK ▫  Head is only dependent on the Name through the Workgroup column
  37. 37. Surrogate Keys •  Natural Key (NK) is a CK with a natural relationship to that row •  Surrogate Key (SK) is an artificially added unique identifier ▫  Since they are artificial they make queries harder to readand can lead to more joins •  Integers do not significantly improve JOIN performance or reduce file I/O for many data sets
  38. 38. Bareword ids •  Makes SQL less obvious to read ▫  SELECT id, id, id FROM foo, bar, baz WHERE … ▫  Makes ANSI JOIN syntax more cumbersome JOIN foo USING (bar_id) ▫  JOIN foo ON (foo.bar_id = bar.id) •  Often resort to alias columns to add clarity, scoping •  Some ORMs really like this (can be overridden •  Use verbose id names instead ▫  Create table actor (actor_id, full_name text);
  39. 39. Use standard definitions •  Often data has been designed in a standard way ▫  Country Code ▫  Email address ▫  Zip Code ▫  VIN ▫  SEX (ISO 5218) •  Helps eliminate short-sightedness •  Increases commonality across projects
  40. 40. Images in the database •  Replication •  Backups •  Access control •  Transactions •  OS Portability
  41. 41. Over indexing •  Indexes must be updated when data changes occur ▫  INSERT/UPDATE/DELETE all touch indexes ▫  Some like it HOT, pg_stat_all_tables •  BitMap vs. Multi-Column Indexes ▫  Combine index on (a) and (b) in memory ▫  Index on (x,y,z) implies index on (x) and (x,y) •  Make sure indexes are used ▫  pg_stat_all_indexes
  42. 42. Covering indexes •  Creating indexes to avoid accessing data in the table ▫  TOAST makes this less necessary ▫  Visibility information stored in the table
  43. 43. Full text indexing •  IT ROCKS! •  Add search engine style functionality to DBMS ▫  LIKE '%foo%' and LIKE '%foo' cannot use index ▫  Regex searching has similar issues ▫  Built-in tsearch functionality in 8.3+   GIN, expensive to update, very fast for searching   GIST, cheaper to update, not as fast for searching •  Database Specific Syntax
  44. 44. Profit
  45. 45. Lessons To Take Away •  PostgreSQL 9.0 is going to rock •  Never confuse a company with community •  Some mistakes are just to much fun to make only once •  Never ask for directions from a two-headed tourist! -Big Bird
  46. 46. Thanks to •  The PostgreSQL Community! •  Robert Treat •  Hubert Lubaczewski •  More info: ▫  http://www.depesz.com/ ▫  http://www.xzilla.net/
  47. 47. Questions •  Web: http://www.chasingnuts.com •  Email: aaron@chasingnuts.com •  IRC: AaronThul on irc.freenode.org •  Jabber: apthul@gmail.com •  Twitter: @AaronThul •  AIM: AaronThul

×