Skip site navigation (1) Skip section navigation (2)

Re: To Do wiki

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: To Do wiki
Date: 2012-04-10 06:27:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 10.04.2012 03:32, Jeff Janes wrote:
> The To Do wiki says not to add things to the page with discussing here.
> So here are some things to discuss.  Assuming the discussion is a
> brief yup or nope, it seems to make sense to lump them into one email:
> Vacuuming a table with a large GIN index is painfully slow, because
> the index is vacuumed in logical order not physical order.  Is making
> a vacuum in physical order a to-do?  Does this belong to vacuuming, or
> to GIN indexing?  Looking at the complexity of how this was done for
> btree index, I would say this is far from easy.  I wonder if there is
> an easier way that is still good enough, for example every time you
> split a page, check to see if a vacuum is in the index, and if so only
> move tuples physically rightward.  If the table is so active that
> there is essentially always a vacuum in the index, this could lead to
> bloat.  But if the table is that large and active, under the current
> non-physical order the vacuum would likely take approximately forever
> to finish and so the bloat would be just as bad under that existing
> system.

Yup, seems like a todo. It doesn't sound like a good idea to force 
tuples to be moved right when a vacuum is in progress, that could lead 
to bloating, but it should be feasible to implement the same 
cycleid-mechanism in gin that we did in b-tree.

> "Speed up COUNT(*)"  is marked as done.  While index-only-scans should
> speed this up in certain cases, it is nothing compared to the speed up
> that could be obtained by "use a fixed row count and a +/- count to
> follow MVCC visibility rules", and that speed-up is the one people
> used to MyISAM are expecting.  We might not want to actually implement
> the fixed row count +/- MVCC count idea, but we probably shouldn't
> mark the whole thing as done because just one approach to it was
> implemented.

I think the way we'd speed up COUNT(*) further would be to implement 
materialized views. Then you could define a materialized view on 
COUNT(*), and essentially get a row counter similar to MyISAM. I think 
it's fair to mark this as done.

> sort_support was implemented for plain tuple sorting only, To Do is
> extend to index-creation sorts (item 2 from message
> <1698(dot)1323222387(at)sss(dot)pgh(dot)pa(dot)us>)

Index-creation sorts are already handled, Tom is referring to using the 
new comparator API for index searches in that email. The change would go 
to _bt_compare().

   Heikki Linnakangas

In response to

  • To Do wiki at 2012-04-10 00:32:47 from Jeff Janes


pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2012-04-10 06:54:54
Subject: Re: bug in fast-path locking
Previous:From: Amit KapilaDate: 2012-04-10 06:15:25
Subject: Re: [BUGS] BUG #6522: PostgreSQL does not start

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group