Table > 500 Fields

hi,

ich habe gelesen das man nicht so viele Fields haben sollte aber wenn die Quelle schon als DBF existiert …
ich habe auch gelesen das ich dann den “share Memory” ( in postgresql.conf ? ) hoch setzten muss um > 500 Fields in eine Table zu betreiben.

da eine Erhöhung der “blockgrösse” (?) wohl Performance Nachteile hat (?) wüsste ich gerne paar “Hausnummern” für 32bit/4GB bzw. 64bit/8GB. ( nur PostgreSQL )
“wo” muss ich “was” auf welchen “Wert” setzten um bis ca. 600 Fields in einer Table noch Luft zu haben ?

Aus der FAQ: FAQ - PostgreSQL wiki

“Maximum number of columns in a table? 250-1600 depending on column types”


Das hat nix mit Parametern zu tun, sondern mit der max. Page-Size von 8KB.


Davon abgesehen: das ist sehr sicher ein Zeichen für falschen Design. Das JETZT zu fixen hätte für Dich vermutlich eine Reihe handfester Vorteile.


Andreas

em … äh … “page-size 8KB” …
kann eine ROW (alle Fields zusammen) nur 1 Page a 8KB gross sein ?

Maximum size for a row? 400 GB

gibt mir zwar eine Antwort aber nun verstehe ich gar nichts mehr …



YUP … aber ich muss mir erst mal einen Überblick über die Struktur und “Inhalt” der Daten ansehen “können” …

meine Tools sind auch nur für 256 “Felder” ausgelegt, teilweise nur 64 …
deshalb versuche ich die über die libpq.dll in eine Table einzulesen → Fehlermeldung “blabla” … nix verstehen :frowning:

bitte, bitte um hilfe “wie” ich den PG-Server konfigurieren muss damit er bis zu 600 Fields “frisst” wenn ich ihm per

COPY MyTable FROM 'C:\MyData.CSV'

die Daten importieren möchte.
“was” muss ich denn machen, auch wenn nur temporär, damit ich die Daten in mein PG-Server bekomme ?

p.s. ich habe “einzeln” die Felder / Inhalte getestet ( viel “leer” ) sodass die Daten “selbst” wohl nicht das Problem sind.

Wenn Du z.B. TEXT oder BYTEA - Felder hast, so werden dieses geTOASTed ;-), das ist ein spezielles Speicherformat in extra Tabellen, komprimiert und so. Steht alles in der Doku. Wenn Du BOOL-felder anlegst bekommst mehr Spalten unter als mit z.B. BIGINT oder DATE oder so.

Ansonsten: mit Fehlermeldung ‘blabla’ kann auch ich nix anfangen.


Andreas

Hi,

ja, was passiert denn, wenn Du es einfach mal versuchst? Das Risiko kann doch so hoch nicht sein (Backups gemacht?). Akretschmer hat natürlich recht, dass so eine Tabelle dann auch schwer zu handeln ist, aber vielleicht schaffst Du Dir ja einen Überblick, wenn Du alle 600 Felder, aber erstmal nur 100 Datensätze einliest…

cu jth

oooooohh ? em … äh … die Datei Grösse “insgesamt” …
auf die Idee bin ich noch gar nicht gekommen das dass mit “blabla” (sorry) gemeint sein könnte …
gut dann muss ich mir das Log File und die Fehlermeldung noch mal ansehen und es mit weniger Daten Sätzen versuchen, DANKE !

habe mir TOAST & Co angesehen … aber ich bekomme das Puzzle immer noch nicht zusammen was Anzahl Fields und 8 KB “Page-Size” angeht.

ich “zähle” also die “Längen” die Field “Typen” zusammen. bei 100 x Text,10 wären das 1KB (aufgerundet)
ich “müsste” dann doch 500 x Text,10 Fields in einer Table haben können … oder ?

gibt es eine “Formel” zur “Berechnung”, so wie bei SHMMAX

250 kB + 8.2 kB * shared_buffers + 14.2 kB *max_connections bis unendlich

em … äh … na ja vielleicht doch etwas verständlicher :wink:

sorry … ich war so genervt das ich die Fehlermeldung nur weggedrückt habe …
das ganze war auf dem anderen PC und ich muss mal ins Logbuch schauen “was” da nun genau stand.

Die Frage stellt sich bei einem richtigen Tabellendesign nicht, daher ist mir das auch relativ Rille. Wenn Du da forschen willst: read the source.


Andreas