Re: [HACKERS] Revisiting NAMEDATALEN
Tom, thank you for that pointer. I get now that it is not free and therefore why its not something that should be changed by default. I guess the problem is 'build your own copy' (i.e. compiling from source) is something that sends most DB teams running into the hills. A solution might be to make NAMEDATALEN configurable without having to recompile source (perhaps a config variable or an initdb parameter). When I have some free time I will investigate whether this is doable. -- View this message in context: http://www.postgresql-archive.org/Revisiting-NAMEDATALEN-tp5969858p5970351.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Revisiting NAMEDATALEN
Yes, for the example given in the Reddit post I would tend to agree. This is one of those issues where for the most part the solution is better naming conventions but for the few instances where this isn't possible it is a right pain. -- View this message in context: http://www.postgresql-archive.org/Revisiting-NAMEDATALEN-tp5969858p5969860.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Revisiting NAMEDATALEN
Hi hackers, This question came up again on Reddit: https://www.reddit.com/r/PostgreSQL/comments/6kyyev/i_have_hit_the_table_name_length_limit_a_number/ and I thought I'd echo it here. I totally am on board with short, descriptive names and a good convention. However, there are just so many cases where 63 characters can't descriptively describe a column name. I've been on projects where we have one table maybe with only a few thousand records but hundreds of columns each uniquely describing an attribute on the record. It is a challenge bordering on impossible to fit them into a consistently named field of <63 characters that someone can later refer to and know what piece of information it actually refers to. Is this something that can be revisited for an upcoming release? Also, are there any technical problems that would be created by increasing this attribute? -- View this message in context: http://www.postgresql-archive.org/Revisiting-NAMEDATALEN-tp5969858.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Learning to hack Postgres - Keeping track of ctids
I suspect you're right. I've looked at the code and it will be very difficult (especially if I want to do it as an extension rather than patching Postgres) and with all the stuff I'd need to do to make it work you're also right that it probably won't improve upon just using primary key Ids. I've scrapped any further exploration; too hard and no real benefit. -- View this message in context: http://postgresql.nabble.com/Learning-to-hack-Postgres-Keeping-track-of-ctids-tp5923649p5924248.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Learning to hack Postgres - Keeping track of ctids
Thanks Craig, I will look at that code. The alternative I'm considering is whether I can define my own index type on the column storing my array of primary key ids. The index would, for each primary key id just provide a reference to the ctids of the related records. In theory, I think this might be less work. However, I am yet to find a simple/bare index implementation that I can build upon. -- View this message in context: http://postgresql.nabble.com/Learning-to-hack-Postgres-Keeping-track-of-ctids-tp5923649p5923757.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Learning to hack Postgres - Keeping track of ctids
Hi, I'm working on an idea to implement a graph database in Postgres. At the moment its just a learning exercise. What I'd like to do is store a reference to all the links from one record using an array type that stores links to all related tables. At first, I've succeeded in doing this using primary key Ids and this works fine. However, I'd like to be able to bypass the index lookup altogether by storing the ctids in my array instead of the primary key ids. Trouble of course is that ctids can get changed (like for instance vacuuming). So my question is: how can I keep my ctid references up to date - is there any way to detect when a ctid is changed? -- View this message in context: http://postgresql.nabble.com/Learning-to-hack-Postgres-Keeping-track-of-ctids-tp5923649.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
