| From: | Alex Vinogradovs <AVinogradovs(at)Clearpathnet(dot)com> |
|---|---|
| To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
| Cc: | David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com>, Joshua Drake <jd(at)commandprompt(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: non-WAL btree? |
| Date: | 2008-08-01 21:49:43 |
| Message-ID: | 1217627383.79373.64.camel@localhost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
It's all about number of repetions. If say I load my table
with 50k every minute, and run reindex every minute, how
long do you think it would take by end of the day, when
my table (it's daily partition actually) is at maximum
capacity ? And database may actually never crash, and
I won't have to run reindex at all ;)
Btw, SELECT INTO is also a non-WAL operation when
archiving is disabled, or am I missing something ?
Alex.
On Fri, 2008-08-01 at 16:43 -0500, Jaime Casanova wrote:
> On Fri, Aug 1, 2008 at 3:36 PM, Alex Vinogradovs
> <AVinogradovs(at)clearpathnet(dot)com> wrote:
> > It's not that I expect a lot of improvement by having non-WAL
> > indexing, it just sounds logical to me to have that, since
> > index can be re-created fast enough during recovery,
>
> and why you think that? if they are non WAL logged the only way to
> re-create them after a recovery is with a REINDEX... dropping the
> index and create after the bulk is just the same, i think...
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Glen Parker | 2008-08-01 22:10:38 | Re: non-WAL btree? |
| Previous Message | Jaime Casanova | 2008-08-01 21:43:12 | Re: non-WAL btree? |