From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Glen Parker <glenebob(at)nwlink(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: more than one index in a single heap pass? |
Date: | 2009-07-15 19:52:58 |
Message-ID: | 00DEECD0-9F56-4D24-9229-13FC2D1DBBD1@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Le 15 juil. 09 à 02:01, Glen Parker a écrit :
> Sounds to me like another reason to separate index definition from
> creation. If an index can be defined but not yet created or valid,
> then you could imagine syntax like:
>
> DEFINE INDEX blahblah1 ON mytable (some fields);
> DEFINE INDEX blahblah2 ON mytable (some other fields);
> [RE]INDEX TABLE mytable;
>
> ...provided that REINDEX TABLE could recreate all indexes
> simultaneously as you suggest.
Well to me it sounded much more like:
BEGIN;
CREATE INDEX idx_a ON t(a) DEFERRED;
CREATE INDEX idx_b ON t(b) DEFERRED;
COMMIT;
And at commit time, PostgreSQL would build all the transaction indexes
in one pass over the heap, but as Tom already pointed out, using only
1 CPU. Maybe that'd be a way to limit the overall io bandwidth usage
while not consuming too many CPU resources at the same time.
I mean now we have a choice to either sync scan the table heap on
multiple CPU, saving IO but using 1 CPU per index, or to limit CPU to
only 1 but then scan the heap once per index. The intermediary option
of using 1 CPU while still making a single heap scan sure can be
worthwhile to some?
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-15 20:07:09 | Re: Add encoding support to COPY |
Previous Message | Stefan Moeding | 2009-07-15 19:39:51 | Re: Sampling profiler updated |