It seems to me that a separate partition / tablespace would be a much simpler
approach.
On Mar 17, 2010, at 5:18 PM, Hannu Krosing wrote:
On Wed, 2010-03-17 at 16:49 -0400, Greg Smith wrote:
Alvaro Herrera wrote:
Andres Freund escribió:
I find it way much easier to believe such issues
On Thu, 2010-03-18 at 16:12 -0400, Justin Pitts wrote:
It seems to me that a separate partition / tablespace would be a much simpler
approach.
Do you mean a separate partition/ tablespace for _each_ index built
concurrently ?
On Mar 17, 2010, at 5:18 PM, Hannu Krosing wrote:
On Wed,
Yes.
On Mar 18, 2010, at 5:20 PM, Hannu Krosing wrote:
On Thu, 2010-03-18 at 16:12 -0400, Justin Pitts wrote:
It seems to me that a separate partition / tablespace would be a much
simpler approach.
Do you mean a separate partition/ tablespace for _each_ index built
concurrently ?
--
On Wednesday 17 March 2010 22:18:47 Hannu Krosing wrote:
On Wed, 2010-03-17 at 16:49 -0400, Greg Smith wrote:
Alvaro Herrera wrote:
Andres Freund escribió:
I find it way much easier to believe such issues exist on a tables in
constrast to indexes. The likelihood to get sequential
On Wed, 2010-03-17 at 16:49 -0400, Greg Smith wrote:
Alvaro Herrera wrote:
Andres Freund escribió:
I find it way much easier to believe such issues exist on a tables in
constrast to indexes. The likelihood to get sequential accesses on an
index is
small enough on a big table
Rob Wultsch wrote:
Are there any particular performance optimizations that would be in
play in such a scenario?
You'd want to increase maintenance_work_mem significantly, just for the
sessions that are running these. Something like this:
|SET maintenance_work_mem = '1GB';|
I don't know
Greg Smith g...@2ndquadrant.com writes:
Rob Wultsch wrote:
At a minimum I assume that if both of the commands were started at
about the same time they would each scan the table in the same
direction and whichever creation was slower would benefit from most of
the table data it needed being
On Wed, Mar 17, 2010 at 7:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com writes:
Rob Wultsch wrote:
At a minimum I assume that if both of the commands were started at
about the same time they would each scan the table in the same
direction and whichever creation was
On Wednesday 17 March 2010 19:44:56 Greg Smith wrote:
Rob Wultsch wrote:
On Wed, Mar 17, 2010 at 7:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
No, it's not optimistic in the least, at least not since we implemented
synchronized seqscans (in 8.3 or thereabouts).
Where can I find details
Andres Freund escribió:
I find it way much easier to believe such issues exist on a tables in
constrast to indexes. The likelihood to get sequential accesses on an index
is
small enough on a big table to make it unlikely to matter much.
Vacuum walks indexes sequentially, for one.
--
Alvaro Herrera wrote:
Andres Freund escribió:
I find it way much easier to believe such issues exist on a tables in
constrast to indexes. The likelihood to get sequential accesses on an index is
small enough on a big table to make it unlikely to matter much.
Vacuum walks indexes
Lets say I have a large table bigTable to which I would like to add
two btree indexes. Is there a more efficient way to create indexes
than:
CREATE INDEX idx_foo on bigTable (foo);
CREATE INDEX idx_baz on bigTable (baz);
Or
CREATE INDEX CONCURRENTLY idx_foo on bigTable (foo);
CREATE INDEX
On Mar 16, 2010, at 6:04 PM, Rob Wultsch wrote:
Lets say I have a large table bigTable to which I would like to add
two btree indexes. Is there a more efficient way to create indexes
than:
CREATE INDEX idx_foo on bigTable (foo);
CREATE INDEX idx_baz on bigTable (baz);
Or
CREATE INDEX
13 matches
Mail list logo
