Teodor Sigaev wrote: > Interesting feature, but it's not very obvious how to use it. I'd like to > see some example(s) in documentation.
I'm thinking of making a wiki page, because examples pretty much require showing resultsets, and I'm not sure this would fly with our current psql documentation, which is quite compact. The current bit of doc I've produced is 53 lines long in manpage format already. The text has not been proofread by a native English speaker yet, so part of the problem might be that it's just me struggling with english :) > And I see an implementation of AVL tree in psql source code > (src/bin/psql/crosstabview.c). Postgres already has a Red-Black tree > implementation in src/include/lib/rbtree.h and > src/backend/lib/rbtree.c. Is any advantage of using AVL tree here? I > have some doubt about that and this implementation, obviously, will > not be well tested. But I see in comments that implementation is > reduced to insert only and it doesn't use the fact of ordering tree, > so, even hash could be used. Yes. I expect too that a RB tree or a hash-based algorithm would do the job and perform well. The AVL implementation in crosstabview is purposely simplified and specialized for this job, resulting in ~185 lines of code versus ~850 lines for rb-tree.c But I understand the argument that the existing rb-tree has been battle-tested, whereas this code hasn't. I'm looking at rb-tree.c and thinking what it would take to incorporate it: 1. duplicating or linking from backend/lib/rb-tree.c into psql/ 2. replacing the elog() calls with something else in the case of psql 3. updating the crosstabview data structures and call sites. While I'm OK with #3, #1 and #2 seem wrong. I could adapt rb-tree.c so that the same code can be used both client-side and server-side, but touching server-side code for this feature and creating links in the source tree feels invasive and overkill. Another approach is to replace AVL with an hash-based algorithm, but that raises the same sort of question. If crosstabview comes with its specific implementation, why use that rather than existing server-side code? But at a glance, utils/hash/dynahash.c seems quite hard to convert for client-side use. I'm open to ideas on this. In particular, if we have a hash table implementation that is already blessed by the project and small enough to make sense in psql, I'd be happy to consider it. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers