Im not even close to a DBA, so plain English please. I recently needed to look into a performance issue on a relatively small PG database, but yet is performing very slow. the server is running PGSql 9.0.22. Its largest table is about 30Mb, and the entire db is hardly 80Mb. However, i found that one of the tables has a text column (which i assume has no width limit) which probably stretches about 10 miles long. I copied the text from one column into Word, an i got 377 pages and a word count of 69814 (as in sixty eight thousand). Again, im not im not expert, but it just doesnt seem right to me. Can PG handle such large text columns? Is this considered a normal design/practice?
Thank you both for your response. I would have to research its purpose and types of queries running against it. For the sack of argument, lets assume the column has a list of fruits, and is just a point of reference. Meaning, there's a query which just returns a True or Flase if Avocado is on that list, and then moves on to another action based on the True/Flase results. So theres a text "Fruits" column in the "Foods" table, the text in the column might look like this (with just spaces between each fruit):
Apple Avacado Mango Orange Cherry Grape Peach Srawberry ... and on listing about 68,000 fruits
Would it have been beneficial, or perhaps considered a better design, if each fruit was in its own field. In other words, have 68000 fields under the "Fruits" column, as opposed to one text column with 68000 words?
EDIT I didn't mean a column for each fruit. I meant a row for each fruit under the fruit column
**Columns - Fruits, Vegetables** Rows -Apple -Corn -Avocado -Tomatoes -Mango -Orange -Cherry -Grape -Peach -Strawberry
And so on...a list of about 1.5 million
In short, I mean having each piece of data in its own field as opposed to using a large text column. So for example, if this was a spreadsheet, the cell A:1 would be the column (header) and A:2, A:3, A:4 the rows (each holding a fruit name). Not all fruits in A:2.