PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Пролетни конференции на PostgreSQL на 2011 г., САЩ/Канада

Водата тази седмица, падаща от небето, не се превръща в сняг. И в дните, когато е ясно, колата ми е покрита с цветен прашец. Макар да означават нещо различно за повечето хора, за мен това са знаците, че сезонът на пролетните конференции е на път да започне. През всеки от следващите три месеца в Северна Америка има конференция със сериозно PostgreSQL съдържание и тази година правя всяка една от тях.

PgEast 2011 се провежда в Ню Йорк, като започва малко повече от две седмици от сега. Ако сте наблизо, не е твърде късно да направите планове за пътуване. Мястото е толкова лесно за достигане с влак. Мястото на конференцията е точно на върха на Penn Station в Ню Йорк, основен влаков център. Всички големи градове на източното крайбрежие от Бостън до Ричмънд са лесни за пътуване от Пен. Конференцията също е до влакова спирка PATH, с влакове, които водят до и от северен Ню Джърси. Те лесно се свързват с цялата транзитна система на Ню Джърси.

Тазгодишната конференция е огромна, с 5 до 6 паралелни PostgreSQL сесии през много времеви интервали. Има дори песен на MongoDB отгоре. Тази конференция също има голям брой полудневни и целодневни тренировки; те се заплащат отделно от основната конференция. Ако работите с PostgreSQL, очаквам поне една от тези сесии да си струва да пристигнете по-рано.

Реших да направя нещо наистина различно от обичайния формат на обучение. Вместо да преминавам през обикновена серия от слайдове, моята обучителна сесия за Surviving Server Overload ще прекара по-голямата част от времето си, взирайки се в конзолата или инструментите за наблюдение на претоварен PostgreSQL сървър. Идеята е, че ще можете да видите какво търся, когато се опитвам да намеря проблеми с производителността, и да научите малко за методологията, която използвам, за да ги разреша. Извършването на този вид настройка е от съществено значение за много PostgreSQL системи, след като използването им се увеличи. И обикновено се научава само първият начин:  стресиращо, докато се опитвате да разберете защо сървърът се е повредил при натоварване. Моят клас ви позволява да видите как ще изглежда това, преди да се случи, и ви оставя с някои техники и идеи, които да приемете, които могат да отложат прекъсване на производителността да ви се случи – и да ви оставят по-добре подготвени, когато това се случи.
по начина, по който графикът е изготвен, можете да направите цял ден обучение, като видите моя разговор сутринта, след това или обучението за репликация от Магнус или сесията на PostgreSQL 9 от Робърт Трейт следобед. Тук има няколко комбинации, които биха се съчетали добре. Има и някои алтернативи, които заемат целия ден в една сесия, като пример за администриране на Брус.

Трудни избори. Ако някоя от тези обучителни сесии ви интересува, може да се уверите, че ги резервирате възможно най-скоро. Размерите на класовете са доста ограничени и се очаква няколко сесии да бъдат разпродадени.

През април има цяла PostgreSQL песен на все по-грешно наричаната конференция O’Reilly MySQL през април в Санта Клара, Калифорния. Там водя разговор за хардуерния сравнителен анализ, който завършва с някои бележки за тестването на производителността на MySQL спрямо PostgreSQL. Много други популярни PostgreSQL високоговорители също ще бъдат там; това е нещо като „дръжте враговете си по-близо“, ние се смесваме с нашите смъртни врагове в Oracle.

И последната от пролетните конференции е PGCon в Отава, Канада. Графикът за тази конференция току-що се увеличи и аз правя още една половиндневна сесия за настройка на производителността (този по-традиционен разговор, базиран на слайдове) в първия ден от конференцията. Дните за обучение в PGCon често са малко по-посещавани в сравнение с основната конференция. Тъй като Робърт Хаас прави уникален разговор за интроспекцията на базата данни като другата половина на първия ден, тази година определено трябва да пристигнете по-рано в PGCon, ако искате да видите всички добри разговори да бъдат представени.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Има ли удар в производителността при използване на десетични типове данни (MySQL / Postgres)

  2. Операторът не съществува:json =json

  3. Създайте PostgreSQL ROLE (потребител), ако не съществува

  4. Основи за управление на PostgreSQL схеми

  5. Избройте всички последователности в Postgres db 8.1 с SQL