Re: [HACKERS] Limiting factors of pg_largeobject
We're still at cross-purposes then. pg_largeobject doesn't have OIDs (in the sense of per-row OIDs). What I thought you were complaining about was the chosen datatype of the LO identifier column (loid), which happens to be OID. O.k. that was my main concern, which per your statement is unfounded ;). If I don't have to worry about it, then that solves the issue :) regards, tom lane -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Limiting factors of pg_largeobject
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > I was more after the not having an OID than the width of the ID column. We're still at cross-purposes then. pg_largeobject doesn't have OIDs (in the sense of per-row OIDs). What I thought you were complaining about was the chosen datatype of the LO identifier column (loid), which happens to be OID. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Limiting factors of pg_largeobject
pg_largeobject already has an index (which is used by all the LO operations). Again, don't see what the width of the object ID column has to do with it. I was more after the not having an OID than the width of the ID column. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Limiting factors of pg_largeobject
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > The ability to be indexed is obviously there but one problem we have is > that you can't create an index on a system table at least not a user > level index. Is there system level indexes that I am unaware of? pg_largeobject already has an index (which is used by all the LO operations). Again, don't see what the width of the object ID column has to do with it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Limiting factors of pg_largeobject
Breaking all the client-visible LO APIs, for one thing ... Erck. 1. A larger identifier 2. An identifier that is not typed to the underlying system (oid) 3. The ability to be indexed We may benefit. Am I on crack? I don't see what you're getting at with #2 and #3 at all. OID is perfectly indexable. Well number 2 is that we have a limit on total number of OID's yes? Which means we could theorectically run out of OID's because of pg_largeobject. The ability to be indexed is obviously there but one problem we have is that you can't create an index on a system table at least not a user level index. Is there system level indexes that I am unaware of? As for #1, it'd theoretically be useful, but I'm not sure about the real-world usefulness. If your large objects are even moderately "large" (for whatever value of "large" applies this week), you're not likely to be expecting to cram 4 billion of them into your database. If we were doing LOs over for some reason it might be interesting to consider this, but I think they're largely a legacy feature at this point, and not worth that kind of effort. It would be better to put the development effort on creating serial access capability to toasted fields, whereupon LOs would really be obsolete. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Limiting factors of pg_largeobject
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > pg_largeobject uses a loid identifier for the loid. What do we think it > would take to move that identifier to something like bigint? Breaking all the client-visible LO APIs, for one thing ... > I don't really > know the underlying internals of pg_largeboject but it does seem that > if we made it have: >1. A larger identifier >2. An identifier that is not typed to the underlying system (oid) >3. The ability to be indexed >We may benefit. Am I on crack? I don't see what you're getting at with #2 and #3 at all. OID is perfectly indexable. As for #1, it'd theoretically be useful, but I'm not sure about the real-world usefulness. If your large objects are even moderately "large" (for whatever value of "large" applies this week), you're not likely to be expecting to cram 4 billion of them into your database. If we were doing LOs over for some reason it might be interesting to consider this, but I think they're largely a legacy feature at this point, and not worth that kind of effort. It would be better to put the development effort on creating serial access capability to toasted fields, whereupon LOs would really be obsolete. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Limiting factors of pg_largeobject
Hello, pg_largeobject uses a loid identifier for the loid. What do we think it would take to move that identifier to something like bigint? I don't really know the underlying internals of pg_largeboject but it does seem that if we made it have: 1. A larger identifier 2. An identifier that is not typed to the underlying system (oid) 3. The ability to be indexed We may benefit. Am I on crack? Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
