FAQ/he

תורגם ע"י מיכאל גולדברג mic.goldberg@gmail.com

תרגומים של המסמך

• German
• Portuguese
• Spanish
• Русский

שאלות המתאימות לפלטפורמה

למשתמשי Windows מומלץ לקרוא גם את FAQ for Windows platform . קיימים גם FAQs for other platforms.

שאלות כלליות

מהו PostgreSQL? איך זה מבוטא? מהו Postgres?

PostgreSQL מבוטא Post-Gres-Q-L. (למי סקרן לגבי איך לומר "PostgreSQL", [קובץ שמע http://www.postgresql.org/files/postgresql.mp3] זמין.)

PostgreSQL היא מערכת מסד נתונים יחסים אובייקט שיש לה את תכונות של מערכות מסדי נתונים הקנייניות מסורתיות עם שיפורים שאפשר למצוא במערכות DBMS מהדור הבא. PostgreSQL אינה כרוכה בתשלום וקוד מקור המלא זמין.

פיתוח PostgreSQL מבוצע על ידי צוות של מתנדבים ובעיקר מפתחים שהתפשטו ברחבי העולם ובתקשורת דרך אינטרנט. זהו פרויקט קהילתי והוא לא בשליטת של כל החברה. כדי להיות מעורב, ראה שאלות נפוצות הפצה.

Postgres הוא כינוי בשימוש נרחב עבור PostgreSQL. זה היה שם המקור של הפרויקט בברקלי, והוא מועדף יותר לעומת אחרים כינויים. אם אתה מוצא "PostgreSQL" קשה לבטא, קוראים לזה 'Postgres' במקום.

מי שולט ב PostgreSQL?

אם אתם מחפשים שומר סף PostgreSQL, ועד מרכזי, או השליטה בחברה, לוותר --- אין אף אחד. יש לנו וועדת ליבה ו committers CVS, אבל הקבוצות הללו הן יותר עבור למטרות מנהלתיות מאשר שליטה. הפרויקט מנוהל על ידי קהילת המפתחים והמשתמשים, אשר כל אחד יכול להצטרף. כל מה שאתה צריך לעשות הוא להירשם לרשימות התפוצה ולהשתתף דיונים. (ראו גם את Developer's FAQ למידע על איך להיות מעורב בפיתוח PostgreSQL.)

מיהו הקבוצה לפיתוח הגלובלית PostgreSQL?

את "PGDG" הוא התאגדות בינלאומית, לא ממוסדת של יחידים וחברות שתרמו אל PostgreSQL. צוות הליבה של PostgreSQL פועל בדרך כלל כי דוברים עבור PGDG.

מיהו צוות הליבה של PostgreSQL?

ועדה של חמש עד שבע (כיום שש) תורמים בכירים PostgreSQL שעושים דברים הבאים עבור הפרויקט: (א) מגידירים תאריכי שחרור , (ב) עוסקים בנושאים סודיים של הפרויקט, (ג) פועלים בתור דוברים עבור PGDG בעת הצורך, ו- (ד) משמשים כבוררי החלטות הקהילה אשר הם לא התיישבו בהסכמה. צוות הליבה הנוכחי מופיע על גבי דף צוות הליבה

מה לגבי מוסדות PostgreSQL השונים?

בעוד פרויקט PostgreSQL מנצל את תאגידים ללא כוונת רווח ב ארה"ב, אירופה, ברזיל ויפן לגיוס כספים ותיאום פרויקטים, גופים אלה אינם בעלי קוד PostgreSQL.

מהו הרישיון של PostgreSQL?

PostgreSQL מופץ תחת רישיון דומה BSD ו- MIT. בעיקרון, זה מאפשר למשתמשים לעשות מה שהם רוצים עם הקוד, כולל מכירה חוזרת של קבצים בינאריים ללא קוד המקור. ההגבלה היחידה היא כי אתה לא מחזיק אותנו כי אחראים משפטית לגבי בעיות עם התוכנה. יש גם את הדרישה כי זכויות יוצרים זו תופענה בכל העותקים של התוכנה. הנה הרישיון אנו משתמשים:

PostgreSQL Database Management System
(formerly known as Postgres, then as Postgres95)

Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group

Portions Copyright (c) 1994, The Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement
is hereby granted, provided that the above copyright notice and this
paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE PROVIDED HEREUNDER IS
ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO
PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

באילו פלטפורמות תומך PostgreSQL?

באופן כללי, כל פלטפורמה תואמת-יוניקס מודרנית צריכה להיות מסוגל להריץ PostgreSQL. הפלטפורמות אשר קיבלו בדיקות אחרונות מפורשות ניתן לראות ב Build farm. בתיעוד יש פרטים נוספים על פלטפורמות נתמכות ב http://www.postgresql.org/docs/current/static/supported-platforms.html.

PostgreSQL פועל באופן מקורי ב Windows Microsoft NT based מערכות הפעלה כמו Windows XP, Vista, 7, 8, 2003, 2008, וכו' התקנה ארוזה מראש זמינה בכתובת http://www.postgresql.org/download/windows.

Cygwin build עבור Windows קיים אך בדרך כלל לא מומלץ; תשתמשו ב native Windows builds במקום. אתה יכול להשתמש ב Cygwin build of the PostgreSQL client library - libpq על מנת להתחבר ל native Windows PostgreSQL אם אתה באמת צריך Cygwin עבור יישומי לקוח.

איפה אני יכול להשיג PostgreSQL?

ישנן הפצות בינאריות עבור מערכות הפעלה שונות ופלטפורמות; ניתן לראות אזור ההורדות שלנו.

קוד המקור ניתן להשיג באמצעות דפדפן האינטרנט או דרך ftp.

מה היא הגרסה העדכנית ביותר?

המהדורה האחרונה של PostgreSQL מוצגת בעמוד הראשון של אתר האינטרנט שלנו.

יש בדרך כלל המהדורה העיקרית מדי שנה, עם מהדוריות מינורית מדי כמה חודשים. מהדורות מינוריות נעשות בדרך כלל באותו הזמן לכל הענפים של המהדורה העיקרית הנתמכים. למידע נוסף שוני בין מהדורות, ראה http://www.postgresql.org/support/versioning.

איפה אני יכול לקבל תמיכה?

קהילת PostgreSQL מספקת סיוע לרבים משתמשים בו באמצעות הדוא"ל. האתר הראשי להירשם לרשימות הדוא"ל הוא http://www.postgresql.org/community/lists/. הרשימות הכלליות או באגים הם מקום טוב להתחיל בו. לקבלת התוצאות הטובות ביותר, שקול הקריאה guide to reporting problems לפני שתפרסם כדי לוודא שאתה כולל מידע מספיק שאנשים יעזרו לך.

ערוץ IRC העיקרי הוא #postgresql על Libera או irc.libera.chat ערוץ ספרדי קיים באותה רשת, (#postgresql-es), צרפתי, (#postgresqlfr), וברזילאי, (#postgresql-br). יש גם ערוץ PostgreSQL על EFNet.

רשימת חברות תמיכה זמינה בכתובת http://www.postgresql.org/support/professional_support.

כיצד אוכל לדווח על תקלה?

תפתח טופס תקלת PostgreSQL ב http://www.postgresql.org/support/submitbug על מנת לדווח על תקלה שלך ברשימת הדיוור pgsql-bugs. רצוי גם לבדוק אתר ftp שלנו ftp://ftp.postgresql.org/pub כדי לראות אם יש גרסה יותר עדכנית של PostgreSQL.

לקבלת תשובה מהירה ומועילה, חשוב לך לקרוא את guide to reporting problems כדי לוודא שאתה מוסיף את המידע הנדרש כדי להבין ולפעול על הדוח שלך.

תקלה שנשלחה באמצעות טופס תקלה או פורסמה לכל אחת מרשימות התפוצה של PostgreSQL בדרך כלל מייצרת אחת מהתגובות הבאות:

• זאת לא תקלה, ומדוע
• זוהי תקלה ידועה והיא כבר בשימה TODO
• תקלה תוקנה במהדורה הנוכחית
• התקלה תוקנה אך אינה ארוזה עדיין בגרסה רשמי
• הוגשה בקשה לקבלת מידע מפורט יותר:
  1. מערכת הפעלה
  2. גרסת PostgreSQL
  3. טסט שניתן לשיחזור
  4. מידע מ Debugger
  5. Debugger backtrace output
• תקלה חדשה. להלן עלול לקרות:
  1. patch הנוצר וייכלל בגרסה עקרית או מינורית הבא
  2. לא ניתן לתקן את התקלה מיד, יתווספה לרשימת TODO

כיצד אוכל לברר על בעיות מוכרות או תכונות חסרות?

PostgreSQL תומך ב SQL 2008. ראה רשימת TODO עבור בעיות מוכרות, חסרות תכונות, ותוכניות עתידיות.

בקשת תכונה בדרך כלל זה גורמת לאחת מהתגובות הבאות:

• התכונה אינה רצויה כי
  1. זה יוצר כפילות פונקציונליות קיימת שכבר עובדת לפי תקן SQL
  2. התכונה תגדיל מורכבות קוד אבל תוסיף יתרון קטן
  3. התכונה תהיה חסרת ביטחון או לא אמינה
• התכונה החדשה מתווספת לרשימת TODO

PostgreSQL לא משתמשת במערכת המעקב לאחר תקלות, כי אנחנו מוצאים את זה יותר יעיל להשיב לדוא"ל ישירות ולשמור רשימה TODO מעודכנת. בפועל, תקלות לא נמשכות זמן רב במהלך חיי התוכנה, תקלות אשר משפיעים על מספר גדול של משתמשים מתוקנות במהירות. המקום היחיד שאפשר למצוא את כל השינויים, השיפורים ותיקוני בתוך הגרסה של PostgreSQL הוא לקרוא את הודעות יומן CVS. אפילו הערות גרסה לא מפרטות כל שינויים שבוצעו בתוכנה.

תקלה אני נתקל תוקנה בגרסה מינורית חדשה יותר של PostgreSQL, אבל אני לא רוצה לשדרג. האם אני יכול לקבל תיקון פשוט לבעיה זו?

לא, איש לא יעשה תיקון מותאם אישית עבורך, כדי שתוכל (נניח) לחלץ אותו פתרון מ 8.4.3 ולהחיל אותו על 8.4.1. וזה בגלל שאין שום צורך לעשות זאת. אם אתה באמת מרגיש שאתה חייב לעשות את זה תצטרך לחלץ את התיקון מ המקורות בעצמך.

יש ל PostgreSQL מדיניות נוקשת שרק ותיקוני תקלות ייארזו בגרסאות נקודתיות, לפי [מדיניות גרסת http://www.postgresql.org/support/versioning]. זה בטוח לשדרג מ 8.4.1 ל 8.4.3, למשל. תאימות בינארית תישמר, לא נדרש dump או reload, דבר לא ישבור, אבל תקלות שעשויות לגרום לבעיות תוקנו. במקרה גרוע תיקון תקלה עשוי לדרוש reindex לאחר העדכון, ובמקרה זה יתואר בהודעת הגרסה. גם אם אתם עדיין לא נתקלתם בתקלה מסוימת, אתם עלולים להיתקל בזה מאוחר יותר, וזה חכם לשדרג מיד. אתה פשוט צריך להתקין את העדכון להפעיל את שרת מסד הנתונים ומחדש. כדי לקרוא את הערות הגרסה אבל רק לעתים נדירות יש צורך לעשות משהו מיוחד.

שדרוג מ 8.3 ל 8.4, או 8.4 ל 9.0, הוא שדרוג משמעותי ולא מגיע עם אותן הערבויות. עם זאת, אם תקלה מתגלה ב 9.0 ואז היא תוקנה בדרך כלל בכל גרסאות קודמות מתוחזקות כמו 8.4 ו 8.3 אם זה בטוח ומעשי לעשות זאת.

משמעות הדבר היא שאם אתה מריץ 8.1.0, ומשדרג ל 8.1.21 הוא מאוד מומלץ מאוד בטוח. מצד השני, השדרוג לגרסה הגדולה הבאה, 8.2.x, עשוי לדרוש שינויים באפליקציה שלך, ובוודאי ידרוש dup ו וreload או (עבור 8.4+) pg_upgrade; ניתן לראות שדרוג cluster PostgreSQL בתיעוד עבור אפשרויות.

אם אתה רוצה להיות זהיר לגבי כל השדרוגים, אתה צריך לקרוא את הערות שחרור עבור כל נקודה בין בגרסה המשנית הנוכחית שלך ואת הגרסה המשנית האחרונה של אותה גרסה עיקרית בזהירות. אם אתה יוצא דופן פרנואידי לגבי השדרוגים, אתה יכול לשלוף את קוד המקור של כל קבוצה של שינויים לשחרר את הצבע מ מאגר git של PostgreSQL ולבחון אותה.

מומלץ מאוד לבצע תמיד שדרוג לגרסה משנית האחרונה. הימנעו מנסיון לחלץ ולהחיל תיקונים בודדים מגרסה נקודתית; על ידי כך שאתה למעשה עוקף את כל QA המבוצעת על ידי צוות PostgreSQL כשהם מכינים גרסה, ואתה יוצר גרסה המותאמת אישית משלך שאף אחד אחר אי פעם תשתמש . זה הרבה יותר בטוח רק לעדכן לגרסה העדכנית שנבדקה, בטוחה. תיקון מותאם אישי משלך, שאינו סטנדרטי יקח גם יותר זמן או מאמץ לבנות, וכן יחייב אותה הכמות של downtime כי שדרוג רגיל.

יש לי תוכנית שאומרת שהיא רוצה PostgreSQL x.y.1. האם אני יכול להשתמש PostgreSQL x.y.2 במקום?

כל תכנית שפועלת עם גרסה מסוימת, כמו 8.4.1, צריכה לעבוד עם כל גרסה משנית אחרת באותה הגרסה הראשית. זה אומר שאם תוכנית אומרת שהיא רוצה (למשל) 8.4.1, אתה יכול וצריך להתקין את האחרון בסדרה 8.4 במקום.

אם ספק היישום שלך אומר לך אחרת - הפנה אותו את השאלות הנפוצות, ואם הוא עדיין לא השתכנע, תיצור קשר עם רשימת הדיוור pgsql-general כדי שנוכל לפנות אליו. לאלץ את המשתמשים להישאר על גרסה משנית זה מסוכן מטעמי אבטחתמידע ושלמות נתונים.

ראה לשאלה הקודמת לקבלת פרטים נוספים.

איזו תיעוד זמין?

PostgreSQL כולל תיעוד מקיף, כולל מדריך גדול, דפים ידניים, וכמה דוגמאות בדיקה. ראה את ספריית / doc. ניתן גם לגלוש למדריכים מקוונים ב http://www.postgresql.org/docs.

ישנם מספר ספרי PostgreSQL המוצעים למכירה; שניים מהם הם גם זמינים באופן מקוון. רשימת הספרים ניתן למצוא בכתובת http://www.postgresql.org/docs/books/. אחד מאלה הפופולריים ביותר הוא האחד Korry & Susan Douglas.

יש גם אוסף של מאמרים טכניים PostgreSQL על wiki.

ב psql - תכנית שורת הפקודה בצד לקוח יש כמה פקודת \ d על מנת להציג מידע על סוגים, אופרטורים, פונקציות, וכו '- תשתמשו ב- \? כדי להציג פקודות הזמינות.

איך אני יכול ללמוד SQL?

ראשית, כדאי לשקול את הספרים ספציפיים PostgreSQL שהוזכרו לעיל. רבים מהמשתמשים שלנו גם אוהבים את The Practical SQL Handbook, Bowman, Judith S., et al., Addison-Wesley. ואחרים The Complete Reference SQL, Groff et al., McGraw-Hill.

אנשים רבים מחשיבים את תיעוד PostgreSQL כי מדריך מצוין ללימוד עצמי של SQL, כמו גם עבור היישום של PostgreSQL ממנו. לקבלת התוצאות הטובות ביותר תשתמשו ב- PostgreSQL לצד מסד נתונים SQL הכולל את כל תכונות ככל שתלמדו, כך שאתם מתרגלים SQL בלי להיות תלוי בתכונות PostgreSQL ספציפיות. תיעוד PostgreSQL מזכיר בדרך כלל כאשר תכונות הם הרחבות PostgreSQL מן ההתקן.

יש גם הרבה ומדריכים נחמדים הזמינים באופן מקוון:

• sqlcourse.com
• w3schools.com
• sqlzoo.net

כיצד ניתן להגיש בקשה לתיקון או להצטרף לצוות הפיתוח?

ראו את Developer's FAQ.

PostgreSQL בהשוואה ל DBMSs האחרים?

ישנן כמה דרכים למדוד תוכנה: תכונות, ביצועים, אמינות, תמיכה, ומחיר.

תכונות

יש ל PostgreSQL יותר תכונות קיימות מ כל DBMS קניינית גדולה, כגון transactions, subselects, triggers, views, foreign key referential integrity, ונעילה מתוחכמת. יש לנו תכונות מסוימות שאין להם, כמו סוגים המוגדרים על ידי משתמש, ירושה, כללים, multi-version concurrency control על מנת להפחית בעיות בנעילות.

ביצועים

הביצועים של PostgreSQL ניתן להשוות למסדי נתונים קניינים או פתוחים אחרים. זה מהיר יותר עבור דברים מסוימים, איטי לאחרים. הביצועים שלנו הם בדרך כלל +/- 10% לעומת מסדי נתונים אחרים.

אמינות

אנו מבינים כי DBMS חייב להיות אמין, או שזה לא שווה כלום. אנו שואפים לשחרר גרסה בדוקה עם קוד יציב עם מינימום של תקלות. כל גרסה כוללת לפחות חודש אחד של בדיקות בטא, וההיסטורית הגרסאות מראה כי אנו יכולים לספק גרסה יציבה, אמינה ומוכנה לשימוש בייצור. אנו מאמינים שנשווה בחיוב מול מסדי נתונים אחרים בתכונה זו.

תמיכה

רשימות התפוצה שלנו מספקות קשר עם קבוצה גדולה של מפתחים ומשתמשים על מנת לעזור לפתור בעיות שתתקלו. למרות שאנו לא יכולים להבטיח תיקון, DBMSs קנייניות לא תמיד מספקות פתרון גם. גישה ישירה מפתחים, קהילת המשתמשים, מדריכים, ואת קוד המקור הופכים לעתים קרובות תמיכת PostgreSQL להיות ביתרון תחרותי מעל DBMSs האחרות. יש תמיכה מסחרית עבור per-incident זמינה לכל מי שצריך את זה. (ראה section 1.7).

מחיר

אנחנו חופשיים לכל השימוש, מסחרי או פתוח. אתה יכול להוסיף הקוד שלנו למוצר שלך ללא כל מגבלות, פרט לאלה מפורטות ברישיון בסגנון BSD שלנו כאמור לעיל.

האם PostgreSQL יכול להיות מוטבע?

PostgreSQL תוכנן לפי ארכיטקטורה שרת-לקוח, זה דורש תהליכים נפרדים לכל לקוח ושרת, וגם תהליכי עוזר שונים. ארכיטקטורות מוטבעות רבות יכולות לתמוך בדרישות אלה. עם זאת, אם ארכיטקטורה המוטבעת שלך דורשת שרת מסד הנתונים לרוץ בתוך תהליך היישום, אתה לא יכול להשתמש ב Postgres וצריך לבחור פתרון מסד נתונים קל יותר.

אפשרויות פופולריות כוללות SQLite ו SQL Firebird.

כיצד ניתן להסיר את עצמך מרשימות הדוא"ל PostgreSQL? כיצד ניתן להימנע מקבלת הודעות דוא"ל כפולות?

דף PostgreSQL Majordomo מאפשר להירשם או לבטל מנוי מכל רשימות הדוא"ל PostgreSQL. (ייתכן שתהיה עליך להשתמש בסיסמא Majordomo שנשלחה אליך על מנת להתחבר.)

כל רשימות תפוצת PostgreSQL מוגדרות כך שתשובה מן הקבוצה הולכת לרשימת התפוצה בדוא"ל הדוא"ל המקורי של המשתמש. זה נעשה על מנת שמשתמשים יקבלו את התשובות האפשריות המהירות בדוא"ל. אם אתה מעדיף שלא לקבל דוא"ל כפול מהרשימה במקרים בהם אתה כבר מקבל הודעת דוא"ל ישירות, תבדוק eliminatecc מהדף הגדרות Majordomo Change Settings. אתה יכול גם למנוע מעצמך מפני קבלת העתקים של הודעות דוא"ל שתפרסם לרשימות על ידי ביטול selfcopy.

שאלות לקוח משתמש

מה ממשקים זמינים עבור PostgreSQL?

קוד מקור PostgreSQL הליבה כולל רק את C וממשקי C מוטבע. כל הממשקים האחרים הם פרויקטים עצמאיים אשר מאוחסנים בתיקיות נפרדות; להיות נפרד מאפשר להם לתחזק לוח זמנים לגרסאות וצוותי פיתוח משלהם.

ממשקי הלקוח רבים מתקינים חבילת השפה PostgreSQL כמו PgJDBC, nPgSQLPgJDBC, nPgSQL, the Pg ruby gem, psycopg2 for Python, DBD::Pg for Perl, וכו' לתוך ההתקנה PostgreSQL או מציעים להוריד אותם בשבילך. בנוסף, חלק מזמני ריצה של שפת התכנות מגיעים עם ספריות לקוח PostgreSQL מותקנת מראש.

במערכות לינוקס באופן כללי תוכל פשוט להתקין אחת משפות כמו psycopg2 באמצעות package manager שלך.

אילו כלים זמינים לשימוש ב- PostgreSQL עם דפי אינטרנט?

מבוא נחמד לדפי אינטרנט בגיבוי Database ניתן לראות בכתובת: http://www.webreview.com

עבור שילוב אינטרנט, PHP הוא ממשק מעולה.

למקרים מורכבים, רבים להשתמש Perl ו- DBD :: Pg עם CGI.pm או mod_perl.

האם יש ל PostgreSQL ממשק משתמש גרפי?

ישנם מספר רב של כלי GUI זמינים עבור PostgreSQL והן ממפתחי קוד מסחריים וחופשיים. ניתן למצוא רשימה מפורטת של [כלי GUI [מדריך קהילת PostgreSQL]].

מתקינים רבים מאגדים ממשק גרפי בצד לקוח [PgAdmin-III] [] עם ההתקנה.

שאלות מנהלתיות

כאשר התקנה מקוד המקור, איך אני מתקין PostgreSQL במקום אחר שאינו / usr / local / pgsql?

ציין את האפשרות --prefix בעת הפעלת configure.

אני מתקין PostgreSQL ב- Windows או OS X ולא יודע את הסיסמה עבור משתמש postgres

Dave Page כתב [פוסט בבלוג http://pgsnake.blogspot.com/2010/07/postgresql-passwords-and-installers.html] הסבר מה ססמאות שונות שמשתמשים בהן, וכיצד ניתן להתגבר על בעיות נפוצות כגון איפוס.

PostgreSQL 9.2 עכשיו רץ כמו NETWORKSERVICE ב- Windows, כך שהוא לא צריך סיסמא לחשבון שירות יותר, ויש לו רק את הסיסמא עבור המשתמש באתר "postgres".

כיצד אוכל לשלוט בחיבורים ממחשבים אחרים?

כברירת מחדל, PostgreSQL רק מאפשר חיבורים מהמכונה המקומי באמצעות Unix domain sockets או חיבורי TCP/IP. מכונות אחרות לא תוכלנה להתחבר אם תשנו את listen_addresses בקובץ postgresql.conf, תפעילו host-based authentication על ידי שינוי קובץ $PGDATA/pg_hba.conf, ותפעילו מחדש את שרת מסד הנתונים.

כיצד ניתן לכוון את מנוע מסד הנתונים עבור ביצועים טובים יותר?

ישנם שלושה תחומים עיקריים לשיפור ביצועים פוטנציאלי:

שינויי שאילתות

זה כרוך בשינוי שאילתות להשגת ביצועים טובים יותר:

• יצירת אינדקסים, כולל ביטויים ואינדקסים חלקיים
• שימוש ב COPY במקום INSERTs מרובים
• קיבוץ פקודות מרובות לתוך transaction אחת כדי להפחית תקורה של commit
• שימוש ב CLUSTER בעת שיחזור שורות רבות מן אינדקס
• שימוש ב LIMIT להחזרת קבוצת משנה של הפלט של השאילתה
• שימוש ב Prepared queries
• שימוש ב ANALYZE כדי לתחזק סטטיסטיקת האופטימיזציה מדויקת
• שימוש קבוע ב VACUUM או pg_autovacuum
• הטלת אינדקסים בזמן שינויי נתונים גדולים

תצורת שרת

מספר הגדרות postgresql.conf משפיע על הביצועים. לפרטים נוספים, ראה Administration Guide/Server Run-time Environment/Run-time Configuration.

בחירת חומרה

השפעת חומרה על ביצועים מפורטת ב http://www.powerpostgresql.com/PerfList/ ו http://momjian.us/main/writings/pgsql/hw_performance/index.html.

אילו תכונות debugging זמינות?

ישנם משתני ה רבים log_* ב http://www.postgresql.org/docs/current/interactive/runtime-config-logging.html המאפשרים הדפסה השאילתה וסטטיסטיקות תהליך אשר יכולים להיות שימושיים מאוד עבור debugging ומדידות ביצועים.

מדוע אני מקבל "Sorry, too many clients" כאשר מנסה להתחבר?

הגעת למגבלה של ברירת המחדל של 100 חיבורים למסד נתונים. ראה Number of database connections עם עצה אם אתה צריך להעלות את מספר החיבורים או להוסיף connection pooler.

מהו תהליך השדרוג עבור PostgreSQL?

ראה http://www.postgresql.org/support/versioning לדיון כללי עבור שדרוג, ואת http://www.postgresql.org/docs/current/static/upgrading.html לקבלת הוראות ספציפיות עבור שדרוג של PostgreSQL cluster.

אם השתמשת מתכנית התקנה, תבדוק האם יש הוראות ספציפיות הקשורות לתכנית התקנה של PostgreSQL שהשתמשת.

האם PostgreSQL תתחזק שינויים ל שעון הקיץ במדינות שונות?

PostgreSQL מגרסה 8.0 ומעלה תלוי במאגר מידע tzdata שבשימוש נרחב (המכונה גם במאגר zoneinfo או Olson timezone database) לקבלת מידע הודות שעון קיץ. כדי להתמודד עם שינוי DST המשפיעה לך, התקן קובץ tzdata חדש ותפעיל מחדש את השרת.

כל הגרסאות העדכניות של PostgreSQL כולות את הקבצים tzdata הזמינים האחרונים, ולכן שמירת עדכונים לגרסה העיקרית שלך היא בדרך כלל מספיק עבור זה.

בפלטפורמות המקבלות עדכוני תוכנה רגילות כולל קבצי tzdata חדשים, זה יכול להיות יותר נוח להסתמך על העותק של מערכת. זה אפשרי כ compile-time option. רוב הפצות הלינוקס בחרו בגישה זו עבור גרסאות pre-built שלהם של PostgreSQL.

PostgreSQL מגרסה לפני 8.0 תמיד הסתמכו על אזור הזמן של מערכת ההפעלה.

מה חומרת מחשב שכדאי לי להשתמש?

בגלל שחומרת מחשב תואמת לרוב, אנשים נוטים להאמין כי כל חומרת PC היא באיכות שווה. אך זה לא. ECC RAM, כוננים קשיחים באיכות טובה/כוננים SSD, ספקי כוח אמינים, ולוחות אם איכותיים יותר אמינים ויש להם ביצועים טובים יותר מאשר חומרה פחות יקרה. PostgreSQL ירוץ על כמעט כל חומרה, אבל אם אמינות וביצועים הם חשובים לך יהיה זה נבון כדי לחקור אפשרויות החומרה שלך ביסודיות.

שרתי מסד נתונים, בניגוד ליישומים רבים אחרים, הם בדרך כלל מוגבלים I/O וזיכרון, ולכן יהיה זה נבון להתמקד על מערכת המשנית I/O ראשונה, ואז בקיבולת זיכרון, ולבסוף לשקול בעיות CPU. SSD באיכות טובה עם ביצועים גבוהים בדרך כלל הדרך הזולה ביותר כדי לשפר את ביצועי מסד נתונים. רשימות התפוצה שלנו יכולות לשמש כדי לדון באפשרויות חומרת ו tradeoffs.

איך PostgreSQL משתמש במשאבי המעבד?

שרת PostgreSQL הוא מבוסס תהליך (לא threaded), ומשתמש בתהליך מערכת הפעלה אחת לכל חיבור למסד. session אחד (connection) לא יכול לנצל יותר מ CPU אחד. כמובן, sessions מרובות מופצות אוטומטית בכל המעבדים הזמינים על ידי מערכת ההפעלה. יישומי לקוח יכולים להשתמש ב threads בקלות וליצור חיבורים מרובים למסד נתונים מכל thread.

שאילתא אחת מורכבת ועתירת CPU אינה מסוגלת להשתמש ביותר מ CPU אחד. מערכת ההפעלה עשויה עדיין להיות מסוגלת להשתמש באחרים לי דיסק I/O וכו', אבל אתה לא תראה הרבה תועלת ביותר ליבה אחת חלופית.

מדוע PostgreSQLמשתמש בזיכרון כל כך רב?

למרות מה שנדמה, זה נורמלי לחלוטין, ואין בעצם מתקרב לזו הרבה זיכרון שבשימוש של כלים כמו ב top או על גבי תצוגת תהליכים של Windows שPostgreSQL משתמש.

כלים כמו top וWindows process monitor עשויים להראות רב postgres מופעים (ראה לעיל), שכל אחד מהם עשוי להשתמש בכמות עצומה של זיכרון. לעתים קרובות, לאחר הסיכום של הזיכרון שבשימוש התוצאה היא ש Postgres משתמש ביותר הזיכרון מאשר מותקן בעצם במחשב!

זוהי תוצאה של איך כלים אלה מדווחים על שימוש בזיכרון. הם בדרך כלל לא מבינים זיכרון משותף היטב, ומראים את זה כאילו זה היה זיכרון לשימוש בנפרד ובאופן בלעדי על ידי כל מופע של PostgreSQL .PostgreSQL משתמשת בנתח גדול של זיכרון משותף כדי לתקשר בין backends וcache data שלו. בגלל שכלים אלה סופרים בלוקים של זכרון המשותף עבור כל מופע של postgres במקום לספור את זה פעם אחת עבור כל המופעים של postgres, הם מראים אומדן יתר מופרז ומסיבי של כמה זיכרון PostgreSQL משתמש.

יתר על כן, גרסאות רבות של כלים אלה אינם מדווחים את הבלוק הזיכרון המשותף כולו שהיה בשימוש על ידי מופע יחיד מיד כשזה מתחיל, אלא סופרים את מספר העמודים משותפים זה נגע מאז שהחל. במשך החיים של מופע, זה יהיה בלתי נמנע מלגעת יותר ויותר של זיכרון משותף עד שהוא נגע בכל דף, ולכן השימוש המדווח יעלה בהדרגה ויכלול את בלוק זיכרון המשותף כולו. זה שלא כהלכה לעתים קרובות מפושרת כי דליפת זיכרון; אבל זה שום דבר כזה, אלא דיווח חפץ בלבד.

שאלות תפעוליות

איך אני בוחר רק את השורות הראשונות של שאילתה? שורה אקראית?

כדי לאחזר רק כמה שורות, אם אתה יודע את מספר השורות הדרוש בזמן ביצוע של SELECT - תשתמש ב LIMIT. אם אינדקס תואם את ORDER BY אזי זה אפשרי שהשאילתה לא צריכה להיות מבוצעת. אם אינך יודע את מספר השורות בשעת SELECT, השתמש cursor וFETCH.

כדי לבחור שורה אקראית, השתמש:

SELECT col
FROM tab
ORDER BY random()
LIMIT 1;

ראה גם זה הבלוג של Andrew Gierth אשר כולל מידע נוסף בנושא זה.

איך אני יכול לדעת מה טבלאות, אינדקסים, מאגרי מידע, ומשתמשים מוגדרים? איך אוכל לראות את שאילתות בשימוש באמצעות psql כדי להציג אותן?

השתמש בפקודה \dt gk nbm לראותאת הטבלאות ב psql. לקבלת רשימה מלאה של פקודות בתוך psql אתה יכול להשתמש \?. לחילופין אתה יכול לקרוא את קוד המקור של psql ב pgsql קובץ pgsql/src/bin/psql/describe.c, הוא מכיל פקודות SQL שיוצרות את הפלט עבור פקודות הקו הנטוי ההפוך של psql. אתה יכול גם להתחיל psql עם אפשרות -E אז היא תדפיס את השאילתות היא משתמשת כדי לבצע את הפקודות שאתה נותן. PostgreSQL גם מספק ממשק INFORMATION SCHEMA תואם SQL שבו אתה יכול לבצע שאילתות כדי לקבל מידע על מסד נתונים.

יש גם בטבלאות המערכת המתחילות מ pg_ שמתארות מידע זה.

השימוש ב psql -l יפרט את כל מסדי הנתונים.

נסו גם את קובץ pgsql/src/tutorial/syscat.source. הוא ממחיש את רב ה SELECTs דרושים לקבל מידע מן טבלאות המערכת של מסד נתונים.

איך אתה יכול לשנות את סוג הנתונים של עמודה?

שינוי סוג הנתונים של עמודה יכול להיעשות בקלות מגרסה 8.0 ומאוחר יותר עם ALTER TABLE ALTER COLUMN TYPE.

במהדורות קודמות, היה ניתן לעשות זאת:

BEGIN;
ALTER TABLE tab ADD COLUMN new_col new_data_type;
UPDATE tab SET new_col = CAST(old_col AS new_data_type);
ALTER TABLE tab DROP COLUMN old_col;
COMMIT;

ייתכן שלאחר מכן תרצה לעשות VACUUM FULL TAB כדי לפנות את שטח הדיסק אשר בשימוש על ידי השורות שפג תוקפן.

מהי הגודל המרבי עבור שורה, טבלה ובסיס נתונים?

אלה הם גבולות:

גודל מרבי עבור מסד נתונים? ללא הגבלה (קיימים מסדי נתונים של 32 TB)
גודל מרבי עבור טבלה? 32 TB
גודל מרבי עבור שורה? 400 GB
גודל מרבי עבור שדה? 1 GB
מספר מרבי של שורות בטבלה? ללא הגבלה
מספר מרבי של עמודות בטבלה? 250-1600 תלוי בסוגי העמודות
מספר מרבי של אינדקסים בטבלה? ללא הגבלה

כמובן, אלה אינם למעשה בלתי-מוגבלים, אבל מוגבלים לשטח דיסק פנוי ומרחב memory/swap. ביצועים עלולים להידרדר כאשר ערכים אלו מקבלים גדלים גדולים במיוחד.

גודל הטבלה עד 32 TB אינו מחייב תמיכה בגדול הקובץ ממערכת ההפעלה. טבלאות גדולות מאוחסנות בקבצים של GB 1 וכך מגבלות גודל הקבצים של מערכת קבצים אינן חשובות.

גודל הטבלה המקסימלי, גודל השורה, ואת המספר המרבי של עמודות יכול להיות מוגדל פי ארבעה על ידי הגדלת גודל ברירת המחדל של בלוק עד 32k. גודל הטבלה המקסימלי יכול גם להיות מוגבר באמצעות table partitioning.

מגבלה אחת היא כי אינדקסים לא ניתן ליצור לעמודות ארוכות יותר מ -2,000 תווים. למרבה המזל, באינדקסים כאלה לעתים נדירות יש צורך. ייחוד מובטח בדרך הטובה ביותר באמצעות function index של HashMD5 hash של העמודה הארוכה, ויצירת אינדקס טקסט מלא מאפשר לחפש לאחר מילות בתוך העמודה.

שים לב, אם אתה מאחסן טבלה עם שורות העולות על 2KB בגודלם (גודל כולל של נתונים בכל שורה) אז "המספר המרבי של שורות בטבלה" עשוי להיות מוגבל ל -4 מיליארדים או פחות, ראה TOAST.

כמה שטח דיסק עבור מסד נתונים נדרש כדי לאחסן נתונים מקובץ טקסט אופייני?

PostgreSQL עשוי לדרוש עד פי חמש פעמים את שטח הדיסק לאחסון נתונים מתוך קובץ טקסט.

כדוגמה, תחשוב על קובץ של 100,000 שורות עם מספר שלם וטקסט בכל שורה. תניח שאורך ממוצע של מחרוזות הטקסט הוא עשרים בתים. הקובץ יהיה 2.8 MB. גודלו של קובץ מסד הנתונים PostgreSQL המכיל נתונים אלה ניתן לאמוד כי 5.2 MB:

24 בתים: בכותרת כל שורה (משוער)
24 בתים: שדה int אחד ושדה טקסט אחת
+ 4 בתים: מצביע ל tuple
----------------------------------------
52 בתים לכל שורה

גודל דף הנתונים PostgreSQL הוא 8192 בתים (8 KB), כך:

8192 בתים לכל דף
------------------- = 158 שורות לעמוד בבסיס נתונים (מעוגל כלפי מטה)
52 בתים לכל שורה

גודל דף הנתונים PostgreSQL הוא 8192 בתים (8 KB), כך:

100000 שורות נתונים
------------------ = 633 דפים בבסיס הנתונים (מעוגל כלפי מעלה)
158 שורות לעמוד

633 דפים בבסיס הנתונים* 8192 בתים לכל עמוד =  5,185,536 בתים (5.2 MB)

אינדקסים אינם מחייבים כל כך הרבה תקורה, אך מכילים את הנתונים אשר הוספו לאינדקס, ואז הם יכולים להיות גדולים גם.

Nulls המאוחסנים כמפת סיבית, ולכן הם תופשים שטח קטן מאוד.

שים לב שהערכי long עלולים להיות דחוסים בצורה שקופה.

ראה גם את המצגת הזו על הנושא: File:How Long Is a String.pdf.

למה שאילתות שלי אטיות? למה הן לא משתמשות באינדקסים?

אינדקסים אינם בשימוש על ידי כל שאילתה. אינדקסים משמשים רק אם טבלה גדולה יותר מאשר גודל מינימלי, ואת השאילתה בוחרת רק אחוז קטן של השורות בטבלה. הסיבה לכך היא שהגישה האקראית לדיסק אשר נגרמת על ידי סריקת אינדקס יכולה להיות אטית יותר מאשר קריאה ישירה לטבלה, או הסריקה סדרתית.

כדי לקבוע אם אמורים להשתמש באינדקס, ל PostgreSQL חייב להיות נתונים סטטיסטיים על הטבלה. נתונים אלה נאספים באמצעות VACUUM ANALYZE, או פשוט ANALYZE. ע"י סטטיסטיקה, optimizer יודע כמה שורות הן בטבלה, והוא יכול לקבוע טוב יותר אם יש להשתמש באינדקס. סטטיסטיקות הן גם ערך חשוב בקביעה אופטימלית לסדר של join או שיטות של join. איסוף סטטיסטיקות צריך להתבצע מעת לעת כפי שתוכן של הטבלה משתנה.

לא משתמשים באינדקסים בדרך עבור ORDER BY או לבצע joins. סריקה סדרתית ואחריה מיון מפורש בדרך כלל מהירים יותר מאשר סריקת אינדקס של טבלה גדולה. עם זאת, LIMIT בשילוב עם ORDER BY לעתים קרובות ישתמש באינדקס משום שרק חלק קטן של הטבלה מוחזרת.

אם אתה מאמין האופטימיזציה אינה נכונה בבחירת סריקה סדרתית, תשתמש ב

SET enable_seqscan TO 'off'

ותריץ את השאילתה שוב כדי לראות אם סריקת האינדקס היא אכן מהירה יותר.

כאשר משתממשים באמצעות אופרטורים wild-card כגון LIKE או ~, ניתן להשתמש באינדקסים רק בנסיבות מסוימות:

• תחילת מחרוזת החיפוש חייב להיות מעוגן תחילת המחרוזת, דהיינו
  1. תבניות LIKE אסור להתחיל עם % או _.
  2. תבניות ~ (regular expression) חייבות להתחיל עם ^.
• מחרוזת החיפוש לא יכולה להתחיל עם character class, למשל, [a-e]
• חיפושים תלויי-רישיות כגון iLike ו ~* לא מנצלים אינדקסים. במקום זאת, תשתמש בexpression indexes, אשר מתוארים ב section 4.8.
• יש לשמש ב locale C במהלך initdb כי מיון ב non-C locale לעתים קרובות אינו תואם את ההתנהגות של LIKE. ניתן ליצור אינדקס text_pattern_ops מיוחד שיעבוד במקרים כאלה, אבל שימו לב שזה מועיל רק לצורך יצירת אינדקס LIKE.

כמו כן ניתן להשתמש באינדקס טקסט מלא עבור חיפושי מילים

שים לב, לעתים אינדקסים נוצרים אך מסומנים "מושחת" וכך לא בשימוש, ראה כאן.

המאמר SlowQueryQuestions מכיל עוד קצת טיפים והדרכה.

איך אוכל לראות איך שquery optimizer בוחן את את השאילתה שלי?

הדבר נעשה באמצעות הפקודה EXPLAIN; ניתן לראות ב Using EXPLAIN.

כיצד ניתן לשנות את סדר המיון של נתונים טקסטואלי?

באופן ספציפי, רוב locales למעט "C" ממיינים לפי סדר המילון, אשר במידה רבה מתעלם בסימני פיסוק וריווח. אם זה לא מה שאתה רוצה אז אתה צריך C locale.

כיצד ניתן לבצע חיפושי לפי ביטוי רגולרי וחיפושי ביטוי רגולרי תלוי רישיות? כיצד אוכל להשתמש באינדקס עבור חיפושים תלוי רישיות?

האופרטור ~ עושה התאמת ביטוי רגולרי, ו ~ * עושה התאמת ביטוי רגולרי תלוי רישיות. הגרסה תלויה רישיות של LIKE נקרא iLike.

השוואות שוויון תלוי-רישיות באים לידי ביטוי בדרך כלל כמו:

SELECT *
FROM tab
WHERE lower(col) = 'abc';

זה לא ישתמש מאינדקס סטנדרטי "col". עם זאת, אם אתה יוצר אינדקס עבור ביטוי על (lower(col, הוא יהיה בשימוש:

CREATE INDEX tabindex ON tab (lower(col));

אם האינדקס שלעיל כי UNIQUE, אז בעמודה ניתן לאחסן תווים גדולים וקטנים, אבל זה לא יכול להכיל ערכים זהים, שההבדל היחיד באות גדולה או קטנה. כדי לאלץ למקרה מסוים להיות מאוחסן בעמודה, תשתמש ב CHECK constraint או trigger.

ב PostgreSQL 8.4 ומאוחר יותר, אתה יכול גם להשתמש ב CITEXT סוג נתונים שנתרם, אשר באופן פנימי מיישם את הקריאות "lower()", כך אתה יכול לטפל בו ביעילות כסוג נתונים לא תלוי-רישיות באופן מלא. CITEXT גם זמין לגרסה 8.3, בעוד שגירסה קודמת שמטפלת בתווי ASCII בלבד כי אינם תלויי-רישיות על 8.2 ומטה זמינה ב pgFoundry.

בשאילתה, איך אני מזהה אם שדה הוא NULL? כיצד ניתן לשרשר nulls אפשריים? איך אני יכול למיין אם השדה הוא NULL או לא?

אתה יכול לבדוק את הערך עם IS NULL או IS NOT NULL, כמו זה:

SELECT *
FROM tab
WHERE col IS NULL;

שירשור NULL עם משהו אחר מייצר עוד NULL.אם זה לא מה שאתה רוצה, אתה יכול להחליף את NULL (ים) באמצעות COALESCE(), כמו זה:

SELECT COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

כדי למיין לפי NULL, ,תשתמש בבדיקות IS NULL או IS NOT NULL בORDER BY. דברים נכונים ימויינו גבוה מהדברים הלא עונים לתנאי, כך שפעטלה הבאה תשים ערכי NULL בהתחלה של הפלט:

SELECT *
FROM tab
ORDER BY (col IS NOT NULL), col;

ב PostgreSQL 8.3 ומעלה, אתה יכול לשלוט בסדר המיון של NULLs באמצעות הכלים שהוספו לתקן לאחרונה NULLS FIRST/NULLS LAST modifiers, ככה:

SELECT *
FROM tab
ORDER BY col NULLS FIRST;

מה ההבדל בין סוגים שונים של טיפוסי character?

Type	Internal Name	Notes
VARCHAR(n)	varchar	גודל מציין אורך מרבי, אין padding
CHAR(n)	bpchar	blank-padded אל אורך קבוע מפורט
TEXT	text	גבול עליון לא ספציפי לאורך
BYTEA	bytea	variable-length byte array (null-byte safe)
"char" (עם המרכאות)	char	בית אחד

אתם תראו את השם הפנימי כאשר בוחנים קטלוגי מערכת ובחלק הודעות שגיאה.

הארבעה הסוגים הראשונים לעיל הם סוגי "varlena" (כך, אורך השדה מאוחסן במפורש בדיסק, ואחריו את הנתונים). כך בפועל השטח התפוס הוא מעט גדול יותר מהגודל הצפוי. עם זאת, ערכים ארוכים כפופים גם לדחיסה, כך שהשטח בדיסק עלול גם להיות פחות מהצפוי.

(VARCHAR(n הוא הבחירה הטובה ביותר כאשר מאחסונים מחרוזות באורך משתנה אם גבול עליון נדרש ע"י היישום. TEXT הוא עבור מחרוזות באורך "בלתי מוגבל" (אם כי כל שדות PostgreSQL מוגבלים לערך מקסימאלי של ג'יגה אחד).

(CHAR(n לאחסון מחרוזות בעלי אותו אורך. (CHAR(n משלימים עם רווחים עד לאורך מסוים, בעוד VARCHAR(n מאחסן רק את התווים המסופקים. BYTEA לאחסון נתונים בינאריים, במיוחד ערכים הכוללים אפס בתים. לכל הסוגים האלה יש מאפייני ביצועים דומים, חוץ מהשלמת הרווחים הקשורה ל (CHAR(n דורשת אחסון נוסף וזמן ריצה נוספת.

סוג "char" (המרכאות נדרשות כדי להבחין בינה לבין (CHAR(n ) הוא סוג נתונים מיוחד שיכול לאחסן בדיוק בייט אחד. הוא מצוי בקטלוגים של מערכת אך השימוש בו בטבלאות של משתמש מייאש בדרך כלל.

איך אני יוצר שדה סדרתי / מקודם אוטומטי?

PostgreSQL תומך בסוג נתונים סדרתי. למעשה, זה לא ממש סוג אמיתי. זהו קיצור ליצירת טור שלם שמקורו מתוך רצף.

לדוגמה:

CREATE TABLE person (
     id SERIAL,
     name TEXT
 );

מתורגם באופן אוטומטי ל:

CREATE SEQUENCE person_id_seq;
 CREATE TABLE person (
     id INTEGER NOT NULL DEFAULT nextval('person_id_seq'),
     name TEXT
 );

הרצף נוצר באופן אוטומטי ונקרא באופן הבא: table_serialcolumn_seq, כאשר table ו serialcolumn הם שמות של הטבלה ו שדה SERIAL, בהתאמה. ראה את המדריך CREATE SEQUENCE לקבלת מידע על רצפים.

יש גם טיפוס BIGSERIAL, שהוא כמו SERIAL חוץ מזה שייווצר הטור מסוג BIGINT במקום INTEGER. השתמש בסוג זה אם אתה חושב כי ייתכן שייווצרו יותר מ -2 מיליארדים ערכים סדרתיים לאורך החיים של הטבלה.

שימו לב רצפים עשויים להכיל "חורים" או "פערים" כחלק טבעי של אופרציה. זה טבעי לחלוטין עבור מפתחות שנוצרו להיות 1, 4, 5, 6, 9, .... ראה the FAQ entry on sequence gaps.

כיצד אוכל לקבל את הערך של הוספת רשומה סדרתית?

הדרך הפשוטה ביותר היא כדי לאחזר את הערך הסדרתי המוקצה עם RETURNING. באמצעות הטבלה מסעיף הקודם, זה ייראה כך:.

INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

ניתן גם לקרוא nextval() ולהשתמש בערך זה ב INSERT או לקרוא ל currval() לאחר INSERT.

האם currval() יכול להוביל למצב race עם משתמשים אחרים?

לא, currval() מחזיר את ערך הסדרתי האחרון שנוצר ב session שלך, לא תלוי במה שקורה ב sessions אחרים.

מדוע יש פערים במספרים בעמודת הרצף / SERIAL? למה אין שימוש חוזר של מספרים כאשר הטרנסאקציה מתבטלת?

כדי לשפר את concurrency, ערכי הרצף ניתנים החוצה לטרנסאקציה שרצה על פי דרישה; אובייקט הרצף לא ננעל וזמין מיידית לטרנסאקציה אחרת כדי לקבל ערך רצף אחר. זה גורם לפערים במספרים מטרנסאקציות מתבטלןת, כפי שתועד ב קטע הערת לפונקציית nextval().

בנוסף, כיבוי השרת בצורה לא תקינה יגרום לרצפים להיות מוגדלים בזמן התאוששות, כי PostgreSQL שומר מטמון של מספרי רצף על מנת להיות מחולקים ובכיבוי לא תקין לא בטוח איזה מספרים במטמון אלה כבר נוצלו. מאז שמותר שלרצפים יהיו פערים בכל מקרה לוקחים את האפשרות הבטוחה ומגדילים את הרצף.

סיבה נוספת לפערים ברצף הוא השימוש של פסקת CACHE ב CREATE SEQUENCE.

באופן כללי, אתה לא צריך להסתמך על מפתחות SERIAL או רצפים להיות ללא פערים בין מספרים, ולא כדאי לכם להניח הנחות על הסדר שלהם; זה "לא" מובטח כי id n + 1 הוכנס לאחר id n למעט כאשר הן נוצרו בתוך אותה העסקה. ניתן להשות מפתחות סינטטיים לשוויון רק לשוויון.

רצפים ללא פערים אפשריים, אך הם משפיעים לרעה בביצועים. לכל היותר טרנסאקציה אחת בכל פעם יכולה להיות להוסיף שורות מתוך הרצף ללא הפערים. אין פתרון מקבילי מובנה לSERIAL או SEQUENCE לרצפים ללא פערים, אבל אחד הוא טריוויאלי ליישם. מידע על יישומים ללא פערים ניתן למצוא בארכיון רשימות התפוצה, ב- Stack Overflow, ו במאמר שימושי זה. הימנע משימוש רצף ללא פערים אלא אם כן זאת דרישה עסקית מובהקת. שקול יצירה דינמית של המספור ללא הפערים לפי דרישה לתצוגה, באמצעות row_number() window function, או הוספתו לתהליך batch שרץ באופן מתוזמן.

ראו גם: FAQ: Using sequences in PostgreSQL.

מהו OID?

אם הטבלה נוצרת עם OIDs, כל שורה כוללת עמודת OID והיא מתמלאת באופן אוטומטי במהלך INSERT. לOIDs מוקצים ברצף מספרים שלמים של 4 בתים. בתחילה הם ייחודיים לאורך ההתקנה כולה. עם זאת, OID counter כרוך סביב 4 מיליארד, ואחרי זה OIDs יכולים להיות מועתקים.

אפשר למנוע שכפול של OIDs בתוך טבלה אחת על ידי יצירת אינדקס ייחודי על עמודת OID (אבל שים לב כי סעיף WITH OIDS כשלעצמה אינה יוצר כזה אינדקס). המערכת בודקת את אינדקס כדי לראות אם OID חדש שנוצר באופן מלאכותי כבר קיים, ואם כן מייצר OID וחוזר חדש. זה עובד היטב כל עוד לא טבלה המכילה-OID יש יותר מ אחוז קטן של 4 מיליארד שורות.

PostgreSQL משתמשת ב OIDs עבור מזהים של האובייקט בקטלוגים של המערכת, איפה מגבלת הגודל אינו צפוי להיות בעיה.

כדי למספר ייחודי שורות בטבלאות למשתמש, עדיף להשתמש ב SERIAL ולא ב OID, או ב BIGSERIAL אם לטבלה צפוים להיות יותר מ -2 מיליארדים רשומות בתוחלת החיים שלה.

מהו CTID?

CTIDs מזהים שורות פיזיות ספציפיות על ידי הבלוק שלהם ואופסט פוזיציות בתוך טבלה. הם נמצאים בשימוש על ידי רשומות אינדקס כך שיצביעו לשורות פיזיות.

CTID לוגי של רשומה משתנה כאשר רשומה מתעדכנת, ולכן CTID לא יכול להיות בשימוש כמזהה רשומה לטווח ארוך. אבל זה לפעמים שימושי לזהות רשומה במסגרת טרנסאקציה כשאף לא צפוי עדכון מתחרה.

מדוע אני מקבל את השגיאה"ERROR: Memory exhausted in AllocSetAlloc()"?

כנראה נגמר הזיכרון הווירטואלי במערכת שלך, או לליבה שלך יש הגבלה עבור משאבים מסוימים. נסה את זה לפני הפעלת השרת:

ulimit -d 262144
limit datasize 256m

בהתאם למערכת שלך, רק פקודה אחת יכולה להצליח, אבל היא תגדיר גבול קטע הנתונים של התהליך שלך הרבה יותר גבוה ואולי תאפשר את השלמת השאילתה. פקודה זו חלה על התהליך הנוכחי, וכל תתי תהליכים הנוצרים לאחר הפקודה הזאת. אם אתה נתקלת בבעיה עם SQL בצד לקוח משום ששרת מחזיר נתונים רבים מדי, נסה את זה לפני הפעלת יישום בצד הלקוח.

איך בודקים איזה הגירסת PostgreSQL אני מפעיל?

הפעל פקודה זו:

SELECT version();

האם יש דרך להשאיר audit trail של פעולות בשרת?

אין שום דבר מובנה, אבל זה לא קשה מדי כדי לבנות כזן פונקציונליות בעצמך.

דוגמה פשוטה מתוך מסמכך הרשמי: http://www.postgresql.org/docs/current/static/plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE

פרויקט מתמקד בתכונה זו: http://pgfoundry.org/projects/tablelog/

מידע נוסף ודוגמאות ליישומים אחרים: http://it.toolbox.com/blogs/database-soup/simple-data-auditing-19014 http://www.go4expert.com/forums/showthread.php?t=7252 http://www.alberton.info/postgresql_table_audit.html

כיצד ניתן ליצור עמודה אשר ערך ברירת מחדל שלה יהיה את השעה הנוכחית?

השתמש ב CURRENT_TIMESTAMP:

CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP);

כיצד ניתן לבצע OUTER JOIN?

PostgreSQL תומך ב OUTER JOINS ומשתמש בתחביר סטנדרטי של SQL. כאן שתי דוגמאות:

SELECT *  FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

או

SELECT *  FROM t1 LEFT OUTER JOIN t2 USING (col);

שאילתות זהות אלה מייחדת t1.col ל t2.col, וגם מחזירות כל שורות לא קשורים ב t1 (אלו ללא התאמה ב- t2). ה RIGHT JOIN תוסיף שורות לא קשורים של t2. ה FULL JOIN יחזיר השורות המתאימות בתוספת כל השורות לא קשורות מ t1 ו- t2. המילה OUTER היא אופציונלית ב LEFT, RIGHT, FULL JOINS. איחודים רגילים נקראים INNER JOINS.

כיצד ניתן לבצע שאילתות באמצעות מסדי נתונים מרובים?

אמנם אין דרך לגשת למסדי הנתונים אחרים ישירות מזה הנוכחי, קיימות גישות שונות לנושא, שחלקם מתוארים להלן.

אמנם אין דרך לגשת למסדי הנתונים אחרים ישירות מזה הנוכחי, קיימות גישות שונות לנושא, שחלקם מתוארים להלן.

SQL / MED תמיכה ב PostgreSQL מאפשרת יצירת "foreign data wrapper", לקשר טבלאות ממסד נתונים מרוחק אל מסד הנתונים המקומי. המאגר מרוחק עשוי להיות מסד נתונים אחר באותו instance של PostgreSQL, או בקצה השני של כדור הארץ, זה לא משנה. postgres_fdw מובנית מPostgreSQL 9.3 וכולל תמיכה בקריאה / כתיבה.

contrib/dblink מאפשר שאילתות צולבות מסדי נתונים באמצעות קריאות לפונקציות, והיא זמינה עבור גרסאות ישנות יותר של PostgreSQL. בניגוד ל postgres_fdw זה לא יכול "push down" תנאים לשרת המרוחק, ובכך זה בדרך כלל מושך הרבה יותר נתונים ממה שאתה צריך.

כמובן, בצד לקוח יכולים גם לבצע חיבורים בו זמנית למסדי נתונים שונים ולמזג את התוצאות.

כיצד אני יכול לחזור מספר שורות או עמודות מפונקציה?

זה קל באמצעות set-returning פונקציות, Return more than one row of data from PL/pgSQL functions.

מדוע אני מקבל שגיאת "relation with OID ##### does not exist" בעת גישת לטבלאות זמניות פונקציות PL/PgSQL?

בגירסאות PostgreSQL קטנות מ 8.3, PL/PgSQL שם במטמון סקריפטים של פונקציות, קיימת תופעת לוואי מצערת היא שאם פונקציה PL/PgSQL ניגשת לטבלה זמנית, והטבלה הזאת נמחקה מאוחר יותר ונוצרה מחדש, והפונקציה נקראה שוב, הפונקציה תיכשל מפני שבמטמון תוכן פונקציה עדיין מצביע לטבלה הזמנית הישנה. הפתרון הוא להשתמש ב EXECUTE עבור גישות לטבלאות זמניות ב PL/PgSQL. זה יגרום השאילתה להיות reparsed בכל פעם.

בעיה זו אינה מתרחשת ב PostgreSQL 8.3 ואילך.

מהם פתרונות השכפול הזמינים?

גם אם המילה "שכפול" הוא מונח יחיד, ישנם מספר טכנולוגיות לעשות שכפול, עם יתרונות וחסרונות לכל אחד מהם. התיעוד שלנו מכיל הקדמה טובה לנושא זה http://www.postgresql.org/docs/current/static/high-availability.html וכן הטבלה עם רשימת תוכנות השכפול ותכונותיהן נמצא ב Replication, Clustering, and Connection Pooling

שכפול master/slave מאפשר master יחיד על מנת לקבל קריאה/כתיבת שאילתות, בעוד slaves יכולים לקבל רק שאילתות לקרוא/SELECT. הפתרון שכפול master/slave הפופולריי ביותר וזמין בחופשיות הוא Slony-I.

שכפול multi-master מאפשר שאילתות קריאה/כתיבה להישלח למחשבים משוכפלים מרובים. יש ליכולת זו גם השפעה חמורה על ביצועים בשל הצורך לסנכרן שינויים בין השרתים. PGCluster הוא הפתרון הפופולרי ביותר זמין בחינם עבור PostgreSQL.

ישנם גם פתרונות שכפול קניינים מבוססי חומרה זמינים לתמוך במגוון דגמים שכפול.

האם ניתן ליצור cluster של שרתי PostgreSQL עם אחסון משותף?

PostgreSQL אינו תומך באשכולות באמצעות אחסון משותף SAN, SCSI backplane, iSCSI volume או מדיה משותפת אחרת. "RAC-style" כאלה clustering אינה נתמכת. רק clustering מבוסס מבוסס כפולים נתמך כרגע.

ראה Replication, Clustering, and Connection Pooling לפרטים.

Shared-storage 'המעבר לגיבוי בעת כשל' אפשרי, אבל זה לא בטוח שיהיה יותר מאחד postmaster רץ וניגש למאגר נתונים בעת ובעונה אחת. Heartbeat ו STONITH או אפשרויות לניתוק שרירותי אחרות מומלצות.

למה שמות הטבלאות או עמודות שלי לא מוכרים בשאילתה? למה אותיות גדולות לא נשמרות?

הסיבה הנפוצה ביותר של שמות הלא מוכרים היא השימוש במירכאות כפולות סביב שמות הטבלאות או עמודות במהלך יצירת הטבלה. כאשר משתמשים במירכאות כפולות, הטבלה ושמות העמודות (המכונים מזהים) מאוחסנים תלוי רישיות, כלומר, אתה חייב להשתמש במרכאות כפולות בעת התייחסות לשמות בשאילתא. ממשקים חלקם, כמו pgAdmin, מזהים במהלך יצירת טבלה מירכאות כפולות אוטומטי. לכן, עבור המזהה להיות מוכר, עליך:

• הימנע מירכאות כפולות במזהים בעת יצירת טבלאות
• השתמש רק אותיות קטנות במזהה
• השתמש במירכאות כפולות ליד מזהה בעת התייחסות אותם השאילתות

איבדתי את הסיסמא ממסד הנתונים. מה אני יכול לעשות כדי לשחזר את זה?

אתה לא יכול. עם זאת, אתה יכול לאפס את הסיסמא למשהו אחר. כדי לעשות זאת, אתה

• לערוך pg_hba.conf לאפשר trust זמני
• טען מחדש את הקובץ config (הטעינה מחדש pg_ctl)
• התחבר והנפק ALTER ROLE / PASSWORD כדי להגדיר את הסיסמא החדשה
• לערוך pg_hba.conf שוב לשחזר את ההגדרות הקודמות
• טען מחדש את הקובץ config שוב

האם ל PostgreSQL יש פרוצדורות מאוחסנות?

לא. עם זאת ל PostgreSQL יש פונקציות מאוד חזקות ויכולות של פונקציות המוגדרות על ידי משתמש שיכולות לעשות את רוב הדברים ששגרות מאוחסנות של RDBMS אחרים (פרוצדורות ופונקציות) יכולות לעשות, ובמקרים רבים אף יותר.

פונקציות אלה יכולים להיות מסוגים שונים יכולות להיות מיושמות במספר שפות תכנות. (עיין בתיעוד לקבלת פרטים נוספים. User-Defined Functions)

ניתן להפעיל פונקציות PostgreSQL בדרכים רבות. אם אתה רוצה להפעיל פונקציה כפי שאתם קורא לפרוצדורה שמורה ב RDBMS אחר (בדרך כלל פונקציה עם תופעות לוואי שתוצאתו לא אכפת לך למשל כיוון שהוא מחזיר void), אפשרות אחת תהיה להשתמש PL/pgSQL Language עבור הפרוצדורה שלך ואת הפקודה PERFORM. לדוגמא:

PERFORM theNameOfTheFunction(arg1, arg2);

שים לב קריאה אחרת:

SELECT theNameOfTheFunction(arg1, arg2);

אף תביא תוצאה גם אם הפונקציה מחזירה void (תוצאה זו תהיה שורה אחת המכילה ערך void).

אפשר להשתמש בPERFORM כדי למנוע תוצאה לא רצוי זו.

המגבלות העיקריות על הפונקציות המאוחסנות של Pg - לעומת פרוצדורות מאוחסנות אמיתיות - הם:

• חוסר יכולת להחזיר קבוצות התוצאות מרובות
• אין תמיכת בטרנזקציות אוטונומיות (BEGIN, COMMIT and ROLLBACK בתוך פונקציה)
• חוסר תמיכה בתקן SQL של התחביר CALL, אם כי מנהלי ההתקנים ODBC ו JDBC יתרגמו הקריאות בשבילך

למה BEGIN, ROLLBACK, COMMIT לא עובדים בפרוצדורות/פונקציות מאוחסנות?

PostgreSQL אינו תומך בטרנזקציות אוטונומיות בפונקציות המאוחסנות שלה. כמו כל שאילתות PostgreSQL, פונקציות מאוחסנות תמיד רצות במסגרת של טרנזקציה ואינן יכולות לפעול מחוץ עסקה.

אם אתה צריך שפרוצדורה מאוחסנת תנהל טרנזקציות, אתה יכול להסתכל לתוך ממשק dblink או לעשות את העבודה על פי תסריט בצד הלקוח במקום. במקרים מסוימים אתה יכול לעשות מה שאתה צריך באמצעות exception blocks in PL/PgSQL, משום כל BEGIN/EXCEPTION/END יוצר תת טרנזקציה.

למה הוא "SELECT count(*) FROM bigtable;" איטי?

ב 9.2 ומעליו בדרך כלל הוא לא בזכות Index-only scans.

לקבלת מידע נוסף על גרסאות קודמות, ראה Slow Counting.

למה השאילתה שלי איטית בהרבה כאשר רצה כי prepared query?

ב PostgreSQL 9.2 ומעלה בעיה זו היא נדירה כי PostgreSQL יכול להחליט להשתמש בתוכנית גנרית או אופטימיזציה לפי ערך על בסיס לכל-ביצוע. המתכנן יכול עדיין לעשות את הבחירה הלא נכונה, כך הבאה נשאר רלוונטי במידה מסוימת:

כאשר ל PostgreSQL יש את השאילתה המלאה עם כל הפרמטרים ידועים בזמן תכנון, הוא יכול להשתמש בסטטיסטיקה של הטבלה כדי לברר אם הערכים שנעשו בם שימוש בשאילתא נפוצים מאוד או מאוד נדירים בעמודה. זה מאפשר למתכנן לשנות את הדרך בה מביא את הנתונים להיות יעילה יותר, כפי שהוא יודע לצפות הרבה או מעט תוצאות מחלק מסוים של השאילתה. לדוגמה, הוא יכול לבחור בסריקה סדרתית במקום לעשות סריקת אינדקס אם אתה מחפש 'active=y' והוא יודע כי ל 99% מהרשומות בטבלה יש 'active=y', כי במקרה זה סריקה סדרתית תהיה הרבה יותר מהרה.

בשאילתא מוכנה, ל PostgreSQL אין מידע של כל הפרמטרים כאשר הוא יוצר את התכנית. יש לו לנסות להרים את התכנית "הבטוחה", שצריכה לעבוד די טוב לא משנה מה ערך שיסופק כפרמטר כשאתה מפעיל את השאילתה המוכנה. למרבה הצער, תכנית זו לא יכולה להיות מתאימה מאוד אם הערך שיסופק הוא יותר נפוץ, או פחות נפוץ, מאשר ממוצע עבור ערכים שנבחרו באקראי בטבלה.

אם אתה חושד שבעיה זו משפיעה עליך, יש להתחיל באמצעות פקודה EXPLAIN להשוות את השאילתות האיטיות ומהירות. תראו את הפלט של EXPLAIN SELECT query... ותשוו אותו לתוצאות של PREPARE query... ; EXPLAIN EXECUTE query... כדי לראות אם התוכניות הן שונות במידה ניכרת. EXPLAIN ANALYZE יכול לתת לך יותר מידע, כגון הערכות ספירת שורות וספירה.

בדרך כלל אנשים נתקלו בבעיה זו מנסים להשתמש בשאילתות מוכנות כאמצעי אבטחה כדי למנוע SQL injection, ולא כאפשרות כוונון ביצועים עבור שאילתות יקרות לתכנת לעתים קרובות עם מגוון רחב של פרמטרים שונים. האנשים האלה צריכים לשקול שימוש בצד לקוח את prepared statements אם ממשק הלקוח שלהם (למשל PgJDBC) תומך בכך. פרוטוקול PostgreSQL תומך ב parameterised queries בלי prepared statements בצד שרת והרבה ממשקים בצד לקוח תומכים בשימוש כי דרך ממשקי prepared statement בצד הלקוח שלהם.

נכון לעכשיו, PostgreSQL אינו מציע דרך לבקש תכנון מחדש של prepared statement באמצעות מערכת מסוימת של ערכי פרמטרים; עם זאת, 9.2 ומעלה רשאי לעשות כן באופן אוטומטי שבו נתונים סטטיסטיים עולים כי רצוי.

ראה Using_EXPLAIN. אם אתה הולך לבקש עזרה על רשימות התפוצה, אנא קרא את Guide to reporting problems.

למה שאילתה שלי איטית בהרבה כאשר לרצה בפונקציה מאשר עצמאימ?

ראה סעיף קודם "למה השאילתה שלי איטית בהרבה כאשר רצה כי prepared query?". שאילתות בפונקציות PL/PgSQL מוכנות ונשמרות במטמון, כך שהם מתבצעות באותו אופן כאילו היית PREPAREd then EXECUTE מריץ אותן בעצמך.

אם אתה נתקלת בבעיות חמורות באמת כך ששיפור סטטיסטיקת הטבלה או התאמת השאילתה שלך לא עוזרים, תוכל לעקוף אותה, תוך ציווי ל PL/PgSQL להכין מחדש את שאילתא בכל ביצוע. לשם כך, השתמש בתחביר <EXECUTE ... USING של PL/PgSQL לספק את השאילתה כמחרוזת טקסטואלי. לחילופין, quote_literal or quote_nullable פונקציות ניתן להשתמש כדי escape פרמטרים להחליף לתוך הטקסט השאילתה.

למה מחרוזות שלי ממוינות באופן שגוי?

ראשית, ודא שאתה משתמש בהגדרות אזוריות אתה רוצה שיהיו בשימוש. השתמש ב- SHOW lc_collate כדי להראות את האזור של מערכות מסדי נתונים בתוקף. אם אתה משתמש איסופים לכל עמודה, תבדוק אותם. אם הכל איך שאתה רוצה, אז תמשיך לקרוא.

PostgreSQL משתמשת בשרותי מיקום של ספריית C למיון מחרוזות. אז אם סדר המיון לא כמו שאתה מצפה, הדבר עלול להימצא בספריית C. אתה יכול לאמת את הרעיון של מיון של ספריית C באמצעות שירות sort על קובץ טקסט, למשל,

LC_COLLATE=xx_YY.utf8 sort testfile.txt

אם זה תוצאות באותו סדר ש PostgreSQL נותן לך, אז הבעיה היא מחוץ ל PostgreSQL.

PostgreSQL סוטה מהתנהגות libc ככל שהיא שוברת את הקשרים על ידי מיון מחרוזות לפי בייט. זה אמור לעתים רחוקות לעשות את ההבדל בפועל, והוא בדרך כלל לא המקור של הבעיה כאשר משתמשים מתלוננים על סדר המיון, אבל זה יכול להשפיע במקרים בהם, למשל, שילוב של תווי Unicode מעורבבים.

אם הבעיה נמצאת בספריית C, תצטרך לקחת את זה עם מתחזק את מערכת ההפעלה. שים לב, עם זאת, כי בעוד שבאגים בהגדרות המיקום של ספריות C כבר ידועים להתקיים, סביר יותר כי ספריית C נכונה, שבו "נכון" פירושו שהיא מוגדרת לפי כמה תקנים בינלאומיים מוכרים או לאומיים. ואולי, אתה מצפה לאחד הפירושים תקפים ממספר של כללי מיון של השפה.

דפוסי תלונות נפוצים כוללים:

• רווחים ותווים מיוחדים: אלגוריתם המיון רגיל עובד בפזות מרובות. ראשית, כל האותיות מושוות, מתעלמים מרווחים וסימני פיסוק. לאחר מכן, רווחים וסימני פיסוק מושווים על מנת לנתק את הקשרים. (זהו פישוט של מה שקורה בפועל.) זה לא ניתן לשנות זאת מבלי לשנות את אזור ההגדרות עצמם (וגם אז זה קשה). אולי אתה רוצה לבנות מחדש את הנתונים שלך מעט כדי להימנע מבעיה זו. לדוגמה, אם אתה ממיין שדה שם, אתה יכול לפצל את השדה לתוך שדות השם הפרטי ושם המשפחה, הימנעות ברווח שביניהם.
• אותיות קטנות/גדולות: הגדרות אשוריות שונות מאזור C בדרך כלל ממיינות אותיות גדולות ואותיות קטנות יחד. אז הסדר יהיה משהו כמו a A b B c C ... במקום A B C ... a b c .. כי הוא מבוסס על ערכים של ASCII. וזה נכון.
• הגדרות האזור הגרמני: סדר המיון של ä כמו a או ae. שתי הדמויות הללו תקפים (ראה http://de.wikipedia.org/wiki/Alphabetische_Sortierung), אבל רוב הספריות C מספקות רק את הראשון. תיקון ידרוש יצירת הגדרת אזור מותאמת אישית. זה אפשרי, אבל ייקח קצת עבודה.
• זה לא הסדר של ASCII / בייט. לא, זה לא, זה לא אמור להיות. ASCII הוא קידוד, לא סדר מיון. אם אתה רוצה את זה, אתה יכול להשתמש בהגדרת האזור של C, אבל אז אתה משתמש ביכולת התווים שאינם ASCII.

עם זאת, אם אתה על Mac OS X או מערכת ההפעלה ממשפחת BSD, ואתה משתמש ב- UTF-8, ואז תוותר. הגדרות האזור על מערכות הפעלה אלה שבורות.

שאלות מידול נתונים

כיצד ניתן להצפין את הנתונים שלי?

ראשית, תראה את המצגת של ברוס Momjian בנושא הכללי של הגנת נתונים. ראה גם [GENERAL] Re: Two-way encryption כנקודת מוצא. שקול אם אתה צריך משהו כמו automatically-encrypted types.