Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
>
> > > It's not particularly clear to me. On its face this seems to me to imply
> > > something about how the index will be able to be used, not about how it
> > > is to be built.
> >
> > Yea, that was always a confusion.
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > It's not particularly clear to me. On its face this seems to me to imply
> > something about how the index will be able to be used, not about how it
> > is to be built.
>
> Yea, that was always a confusion. CREATE CONCURRENT INDEX has the same
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > CREATE [ UNIQUE ] INDEX name ON table
> > [ USING method ] [ [ENABLE] WRITE [ACCESS] ]
> > ( { column | ( expression ) } [ opclass ] [, ...] )
> > [ WITH ( storage_parameter = value [, ... ] ) ]
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> CREATE [ UNIQUE ] INDEX name ON table
> [ USING method ] [ [ENABLE] WRITE [ACCESS] ]
> ( { column | ( expression ) } [ opclass ] [, ...] )
> [ WITH ( storage_parameter = value [, ... ] ) ]
> [ TABLESPACE tab
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > Consindering the syntax for this, we currently allow read access during
> > index creation, just not write access, so I think the new syntax should
> > be:
> >
> > CREATE [ UNIQUE ] INDEX name ON table
> > [ USING method ] [ [ENABLE] WR
Bruce Momjian wrote:
Consindering the syntax for this, we currently allow read access during
index creation, just not write access, so I think the new syntax should
be:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | ( expressi
Consindering the syntax for this, we currently allow read access during
index creation, just not write access, so I think the new syntax should
be:
CREATE [ UNIQUE ] INDEX name ON table
[ USING method ] [ [ENABLE] WRITE [ACCESS] ]
( { column | ( expression ) } [
On Sat, Jul 15, 2006 at 09:10:46PM -0400, Greg Stark wrote:
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > Maybe we can show progress indicators in status line (either
> > pg_stat_activity.current_query or commandline shown in ps), like
> >
> > WAITING TO START PHASE 1 - WAITING FOR TRANSA
On Saturday 15 July 2006 21:37, Joshua D. Drake wrote:
> > That said I'm not sure how much I can do here. For a substantial index we
> > should expect most of the time will be spent in the tuplesort. It's hard
> > to see how to get any sort of progress indicator out of there and as long
> > as we c
Ühel kenal päeval, L, 2006-07-15 kell 21:10, kirjutas Greg Stark:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > Maybe we can show progress indicators in status line (either
> > pg_stat_activity.current_query or commandline shown in ps), like
> >
> > WAITING TO START PHASE 1 - WAITING FOR TRA
On Sat, 2006-07-15 at 21:10 -0400, Greg Stark wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Another related thing - throttling
> > --
> >
> > Did you do any work on using vacuum_cost_* GUC vars to throttle the
> > build process if desired ?
>
> Actually
A great first step would be to add elog(INFO,...) in some standardized
format over the wire so that clients can tell what's going on. It could
be triggered by a GUC which is off by default.
-M
On Jul 15, 2006, at 9:10 PM, Greg Stark wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
Maybe w
That said I'm not sure how much I can do here. For a substantial index we
should expect most of the time will be spent in the tuplesort. It's hard to
see how to get any sort of progress indicator out of there and as long as we
can't it's hard to see the point of getting one during the heap scan
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Maybe we can show progress indicators in status line (either
> pg_stat_activity.current_query or commandline shown in ps), like
>
> WAITING TO START PHASE 1 - WAITING FOR TRANSACTION XXX TO COMPLETE
>
> or
>
> INSERTING INDEX ENTRY N OF M
>
> cha
Ühel kenal päeval, N, 2006-07-13 kell 01:07, kirjutas Greg Stark:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
> > > no regression tests yet.
> >
> > We'll need some performance tests that show that lock-hold time is
> > *actually* reduced,
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
> > no regression tests yet.
>
> We'll need some performance tests that show that lock-hold time is
> *actually* reduced, given the shenanigans needed to get there.
I'm not sure what you mean by "lock-
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
>> no regression tests yet.
> We'll need some performance tests that show that lock-hold time is
> *actually* reduced, given the shenanigans needed to get there.
Reducing lock hold time is not the point
On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
> no regression tests yet.
We'll need some performance tests that show that lock-hold time is
*actually* reduced, given the shenanigans needed to get there.
We may need to have usage recommendations in the docs.
--
Simon Riggs
EnterpriseD
I just sent in the patch for online index builds to -patches.
. The work to combine the two phases into a single non-transactional command
is done. I'm not sure how long to wait between lock checks or how verbose to
be about why it's taking so long. I do think we have to print something or
19 matches
Mail list logo
