| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Hannu Krosing <hannu(at)skype(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Reducing relation locking overhead |
| Date: | 2005-12-12 14:02:50 |
| Message-ID: | 20051212140250.GG19555@surnet.cl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing wrote:
> Ühel kenal päeval, L, 2005-12-10 kell 21:07, kirjutas Tom Lane:
> > In any case the design idea here
> > seems to be "we don't care how long REINDEX takes as long as it's not
> > blocking anyone".
>
> Yes, thats the general idea.
>
> Within reason of course, for example making a seqscan over the index for
> each and every tuple inserted during building the first index would
> probably still be too slow :)
You don't need to seqscan the _index_. You need to scan the table.
Those tuples that do not satisfy the snapshot or where you are in doubt,
you examine the index to see whether they are there. The bulk of it you
just skip.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2005-12-12 14:46:22 | default resource limits |
| Previous Message | Marko Kreen | 2005-12-12 13:40:16 | Re: Log of CREATE USER statement |