Обсуждение: TODO list updates
I have spend the past few days updating our TODO list, removing completed and now-unnecessary items: https://wiki.postgresql.org/wiki/Todo I encourage others to also update the list to make it more accurate. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian <bruce@momjian.us> wrote:
I have spend the past few days updating our TODO list, removing
completed and now-unnecessary items:
https://wiki.postgresql.org/wiki/Todo
Thanks. It can help encourage many new entrants to community.
On Fri, Oct 16, 2015 at 02:50:04PM +0530, Amit Kapila wrote: > On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian <bruce@momjian.us> wrote: > > I have spend the past few days updating our TODO list, removing > completed and now-unnecessary items: > > https://wiki.postgresql.org/wiki/Todo > > > > Thanks. It can help encourage many new entrants to community. I reduced the number of items from 466 to 410. Probably the most controvertial change was to move on-disk bitmap indexes to the "not wanted" section, though I kept the links in case we change our minds. I just can't see how they would be a win with GIN and in-memory bitmaps. (I don't think BRIN indexes help for on-disk bitmap use-cases, do they?) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
Bruce Momjian wrote: > Probably the most controvertial change was to move on-disk bitmap > indexes to the "not wanted" section, though I kept the links in case we > change our minds. I just can't see how they would be a win with GIN and > in-memory bitmaps. Yeah, I recall we discussed bitmap indexes a lot and we found there wasn't a lot of room to use them because GIN is just too good, it seems. Also, the patches that were developed had a number of issues. Anyone wanting to develop bitmap indexes would probably be better off starting from scratch. > (I don't think BRIN indexes help for on-disk bitmap use-cases, do > they?) No, they don't. I expect BRIN to be very bad in a limited domain (which is where bitmap indexes are supposed to shine), except under specific conditions. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Oct 16, 2015 at 11:43:10AM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > Probably the most controvertial change was to move on-disk bitmap > > indexes to the "not wanted" section, though I kept the links in case we > > change our minds. I just can't see how they would be a win with GIN and > > in-memory bitmaps. > > Yeah, I recall we discussed bitmap indexes a lot and we found there > wasn't a lot of room to use them because GIN is just too good, it seems. > Also, the patches that were developed had a number of issues. Anyone > wanting to develop bitmap indexes would probably be better off starting > from scratch. Yes, that was my conclusion too. We have played with the on-disk bitmap idea for a long time, but GIN has gotten very good in that time. Are you suggesting I remove those links? It is kind of odd to have links to patches for features we don't want, or just keep it? > > (I don't think BRIN indexes help for on-disk bitmap use-cases, do > > they?) > > No, they don't. I expect BRIN to be very bad in a limited domain (which > is where bitmap indexes are supposed to shine), except under specific > conditions. Yes, that was my conclusion too. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
Bruce Momjian wrote: > I have spend the past few days updating our TODO list, removing > completed and now-unnecessary items: > > https://wiki.postgresql.org/wiki/Todo Thanks. We have "TodoDone" pages for items that were done in specific releases, but only for 8.4, 9.0 and 9.1. I guess it was too much work to create those. (See https://wiki.postgresql.org/wiki/Category:Todo ). I added a link to the latest posted version of bitmap indexes by Abhijit Menon-Sen, for completeness. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Bruce Momjian wrote: > Are you suggesting I remove those links? It is kind of odd to have > links to patches for features we don't want, or just keep it? No, quite the contrary -- I think the links allow some other person research the issue including the history of patches and discussion, and decide for themselves whether the feature is right to be rejected. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Oct 16, 2015 at 12:00:11PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > I have spend the past few days updating our TODO list, removing > > completed and now-unnecessary items: > > > > https://wiki.postgresql.org/wiki/Todo > > Thanks. We have "TodoDone" pages for items that were done in specific > releases, but only for 8.4, 9.0 and 9.1. I guess it was too much work > to create those. (See https://wiki.postgresql.org/wiki/Category:Todo ). Oh, I had forgotten about that. In some cases I knew the release that completed the item, but in most cases the item had a different approach which was not taken, or was superceeded by a better solution. > I added a link to the latest posted version of bitmap indexes by Abhijit > Menon-Sen, for completeness. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On Fri, Oct 16, 2015 at 12:02:03PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > Are you suggesting I remove those links? It is kind of odd to have > > links to patches for features we don't want, or just keep it? > > No, quite the contrary -- I think the links allow some other person > research the issue including the history of patches and discussion, and > decide for themselves whether the feature is right to be rejected. I think on-disk bitmap indexes would only beat GIN indexes in a read-only database on low-cardinality columns. For example, if you had a purchase_log table and wanted to know all the "blue" and "large" items sold at a specific store, I can see on-disk bitmap indexes doing well there. If you added the product number, or needed read/write, I think GIN would win. I just don't think we have enough deployments who need what on-disk bitmap are best at. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On 16 October 2015 18:20:59 EEST, Bruce Momjian <bruce@momjian.us> wrote: >I think on-disk bitmap indexes would only beat GIN indexes in a >read-only database on low-cardinality columns. For example, if you had >a purchase_log table and wanted to know all the "blue" and "large" >items >sold at a specific store, I can see on-disk bitmap indexes doing well >there. If you added the product number, or needed read/write, I think >GIN would win. I just don't think we have enough deployments who need >what on-disk bitmap are best at. My take on this is that we effectively already have bitmap indexes: it's called GIN. We could make the posting list compressioneven better, currently a TID is compressed at best to a single byte, while in a bitmap index it could go downto one bit, or even less. But that's just a matter of improving the compression algorithm, making it more bitmapy, andcould be done as a fairly isolated change in GIN code. Besides being more dense, there are some other tricks often associated with bitmap indexes. Instead of storing a bitmap/postinglist per each unique value, you could store one for a range of values. That's useful e.g. for storing floats,where you don't have many exact duplicate values, but you could get a dense index by treating all values in range0.0-10.0 as one entry, all values in 10.0-50.0 as another, and so forth. Yet another trick is to have one bitmap forall values > 0.0, another for all values >10.0, and so forth. With that, you can satisfy any BETWEEN query by scanningjust two bitmaps/posting lists: the one for the lower bound and the one for the upper bound. The matching tuplesare the ones that are present in the first, but not the latter posting list. But that's also not a whole new indextype. GIN could do all that, if someone just wrote an opclass for it. - Heikki