Re: [PERFORM] Many fields in one table or many tables?
Josh Berkus <[EMAIL PROTECTED]> writes: > Suggestion 3: There was an issue in 7.3 with table rows which are overly broad > -- some problems with PSQL, I believe. Not sure about PSQL, but I think there still are some performance issues in the backend with SELECTs involving more than a couple hundred targetlist entries. These are probably fixable at not-very-large effort but we haven't made any consistent push to find and fix the trouble spots. The issues that I recall are O(N^2) problems (doubly nested loops) so the performance with ~100 entries is no problem but it gets rapidly worse above that. You could hit this even with ~100-column tables if you try to select all columns from a join of two or more. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] Many fields in one table or many tables?
Alexander, > I am in the process of creating a database design in which LOTS of data > need to be modelled. > > For instance, I need to store data about products. Every product has LOTS > of properties, well over a hundred. > Do any of you know if and how PostgreSQL would prefer one approach over the > other? Queston 1: Do all products have all of these properties, or do some/many/most not have some properties? If the answer is the former, then a single table, however broad, is the logical construct. If the latter, than several tables makes more sense: why create NULL columns for stuff you could just leave out? Question 2: Is it true that some properties will be updated *much* (100x) more frequently than others? If so, it would make sense from a performance/postgresql standpoint to isolate those properties to related table(s). Keep in mind that this recommendation is strictly performance related, and is not necessarily the best relational design. Suggestion 3: There was an issue in 7.3 with table rows which are overly broad -- some problems with PSQL, I believe. It would be worth searching for, as I cannot remember what the limit is where problems occurred. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PERFORM] Many fields in one table or many tables?
Hi guys, I am in the process of creating a database design in which LOTS of data need to be modelled. For instance, I need to store data about products. Every product has LOTS of properties, well over a hundred. So I'm wondering. What's the best approach here, performance wise? Just create one Product table with well over a hundred columns? Or would it be better to divide this over more tables and link them together via ID's? I could for instance create tables Product, PriceInfo, Logistics, StorageInfo, PackagingInfo and link them together via the same ID. This would be easier to document (try to visualize a 100+ column table in a document!), but would it impact performance? I tihnk maybe it would impact Select performance, but Updating of products would maybe speed up a little... All info about a product is unique for this product so records in PriceInfo, Logistics, StorageInfo, PackagingInfo tables would map one to one to records in the Product table. Do any of you know if and how PostgreSQL would prefer one approach over the other? Thanks in advance, Alexander Priem. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
