Re: [patch] Proposal for \rotate in psql
От | Daniel Verite |
---|---|
Тема | Re: [patch] Proposal for \rotate in psql |
Дата | |
Msg-id | 21d1e6f5-c3b6-4509-a668-f85ccd489b32@mm обсуждение исходный текст |
Ответ на | Re: [patch] Proposal for \rotate in psql (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [patch] Proposal for \rotate in psql
Re: [patch] Proposal for \rotate in psql Re: [patch] Proposal for \crosstabview in psql |
Список | pgsql-hackers |
Pavel Stehule wrote: > postgres=# \crosstabview 4 +month label > > Maybe using optional int order column instead label is better - then you can > do sort on client side > > so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol] In the meantime I've followed a different idea: allowing the vertical header to be sorted too, still server-side. That's because to me, the first impulse for a user noticing that it's not sorted vertically would be to write \crosstabview +customer month rather than figure out the \crosstabview customer +month_number month_name invocation. But both ways aren't even mutually exclusive. We could support \crosstabview [+|-]colV[:labelV] [+|-]colH[:labelH] it's more complicated to understand, but not harder to implement. Also, a non-zero FETCH_COUNT is supported by this version of the patch, if the first internal FETCH retrieves less than FETCH_COUNT rows. Otherwise a specific error is emitted. Also there are minor changes in arguments and callers following recent code changes for \o Trying to crosstab with 10k+ distinct values vertically, I've noticed that the current code is too slow, spending too much time sorting. I'm currently replacing its simple arrays of distinct values with AVL binary trees, which I expect to be much more efficient for this. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
Вложения
В списке pgsql-hackers по дате отправления: