Re: BRIN indexes - TRAP: BadArgument
От | Alvaro Herrera |
---|---|
Тема | Re: BRIN indexes - TRAP: BadArgument |
Дата | |
Msg-id | 20141104005923.GW1791@alvin.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: BRIN indexes - TRAP: BadArgument (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-hackers |
Jeff Janes wrote: > On Mon, Nov 3, 2014 at 2:18 PM, Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > I get a couple compiler warnings with this: > > brin.c: In function 'brininsert': > brin.c:97: warning: 'tupcxt' may be used uninitialized in this function > brin.c:98: warning: 'oldcxt' may be used uninitialized in this function Ah, that's easily fixed. My compiler (gcc 4.9 from Debian Jessie nowadays) doesn't complain, but I can see that it's not entirely trivial. > Also, I think it is missing a cat version bump. It let me start the > patched server against an unpatched initdb run, but once started it didn't > find the index method. Sure, that's expected (by me at least). I'm too lazy to maintain catversion bumps in the patch before pushing, since that generates constant conflicts as I rebase. > What would it take to make CLUSTER work on a brin index? Now I just added > a btree index on the same column, clustered on that, then dropped that > index. Interesting question. What's the most efficient way to pack a table to minimize the intervals covered by each index entry? One thing that makes this project a bit easier, I think, is that CLUSTER has already been generalized so that it supports either an indexscan or a seqscan+sort. If anyone wants to work on this, be my guest; I'm certainly not going to add it to the initial commit. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: