Re: [HACKERS] generic LONG VARLENA
От | Zeugswetter Andreas SB |
---|---|
Тема | Re: [HACKERS] generic LONG VARLENA |
Дата | |
Msg-id | 219F68D65015D011A8E000006F8590C603FDC1B8@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: [HACKERS] generic LONG VARLENA
Re: [HACKERS] generic LONG VARLENA |
Список | pgsql-hackers |
> I am excited about the long data type. This is _the_ way to do long > data types. Have any of the commercial databases figured out this way > to do it. I can't imagine a better system. The commercial db's usually make the dba decide on a per column basis whether the value is stored inside the table or in an extra space (blobspace,lobspace ...). They all have propietary syntax for this. (I would probably like it configurabe, whith some reasonable default) It is usually available for the text/byte and user defined datatypes. In PostgreSQL the array types come to mind. What I think would be good is, if you could avoid the need for an index on the _LARGE_.. table. My Idea would be to store an xtid of the first lob page slot in the user table, and have an xtid pointer to the next lob page slot in it, and so on. That way you could avoid indices on the LARGE table. SnapshotAny() would also see the correct long, since an updated value would get a new xtid anyway. No need to use up an extra oid. Since lob's are typically large, the large overhead would be especially painful, so a different relkind with another pagelayout seems adequate. The pointer would imho be: longbit|length|largetableoid|xtid_of_first_lobpage|loblength Just some ideas Andreas
В списке pgsql-hackers по дате отправления: