Postgresql - Optimizing creation of several indexes on one big table










0















What's the best way to create multiple indexes on one very large table (hundreds of Gb).



Currently I have to execute queries like that



create index A on myBigTable (a) using btree ;
create index B on myBigTable (b) using btree ;
create index C on myBigTable (c) using btree ;
....


It takes a very long time. PG has to read all the data from the table several times.



When index on column A is in creation, it prevents from creating an index on column B at the same time.



So, is there a way to optimize the time (and resources consumption) to create all indexes on the same table?



If not possible to really optimize currently, is it something planned for a near future?










share|improve this question



















  • 2





    create index concurrently ... will allow you to create all indexes at the same time (if issued from different connections)

    – a_horse_with_no_name
    Nov 15 '18 at 15:07







  • 1





    Postgres 11 improved the time it takes to create the index as it can use a parallel scan on the table

    – a_horse_with_no_name
    Nov 15 '18 at 15:09











  • thank you @a_horse_with_no_name , but are you sure ? with different connexion, when creating index with 'concurrently', I see that one index is being creating, and others are 'waiting' (wait_evt_typ = lock // wait_evt = relation)

    – Enialis
    Jan 16 at 11:51
















0















What's the best way to create multiple indexes on one very large table (hundreds of Gb).



Currently I have to execute queries like that



create index A on myBigTable (a) using btree ;
create index B on myBigTable (b) using btree ;
create index C on myBigTable (c) using btree ;
....


It takes a very long time. PG has to read all the data from the table several times.



When index on column A is in creation, it prevents from creating an index on column B at the same time.



So, is there a way to optimize the time (and resources consumption) to create all indexes on the same table?



If not possible to really optimize currently, is it something planned for a near future?










share|improve this question



















  • 2





    create index concurrently ... will allow you to create all indexes at the same time (if issued from different connections)

    – a_horse_with_no_name
    Nov 15 '18 at 15:07







  • 1





    Postgres 11 improved the time it takes to create the index as it can use a parallel scan on the table

    – a_horse_with_no_name
    Nov 15 '18 at 15:09











  • thank you @a_horse_with_no_name , but are you sure ? with different connexion, when creating index with 'concurrently', I see that one index is being creating, and others are 'waiting' (wait_evt_typ = lock // wait_evt = relation)

    – Enialis
    Jan 16 at 11:51














0












0








0








What's the best way to create multiple indexes on one very large table (hundreds of Gb).



Currently I have to execute queries like that



create index A on myBigTable (a) using btree ;
create index B on myBigTable (b) using btree ;
create index C on myBigTable (c) using btree ;
....


It takes a very long time. PG has to read all the data from the table several times.



When index on column A is in creation, it prevents from creating an index on column B at the same time.



So, is there a way to optimize the time (and resources consumption) to create all indexes on the same table?



If not possible to really optimize currently, is it something planned for a near future?










share|improve this question
















What's the best way to create multiple indexes on one very large table (hundreds of Gb).



Currently I have to execute queries like that



create index A on myBigTable (a) using btree ;
create index B on myBigTable (b) using btree ;
create index C on myBigTable (c) using btree ;
....


It takes a very long time. PG has to read all the data from the table several times.



When index on column A is in creation, it prevents from creating an index on column B at the same time.



So, is there a way to optimize the time (and resources consumption) to create all indexes on the same table?



If not possible to really optimize currently, is it something planned for a near future?







postgresql optimization indexing






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 '18 at 15:08









a_horse_with_no_name

301k46459552




301k46459552










asked Nov 15 '18 at 14:59









EnialisEnialis

787




787







  • 2





    create index concurrently ... will allow you to create all indexes at the same time (if issued from different connections)

    – a_horse_with_no_name
    Nov 15 '18 at 15:07







  • 1





    Postgres 11 improved the time it takes to create the index as it can use a parallel scan on the table

    – a_horse_with_no_name
    Nov 15 '18 at 15:09











  • thank you @a_horse_with_no_name , but are you sure ? with different connexion, when creating index with 'concurrently', I see that one index is being creating, and others are 'waiting' (wait_evt_typ = lock // wait_evt = relation)

    – Enialis
    Jan 16 at 11:51













  • 2





    create index concurrently ... will allow you to create all indexes at the same time (if issued from different connections)

    – a_horse_with_no_name
    Nov 15 '18 at 15:07







  • 1





    Postgres 11 improved the time it takes to create the index as it can use a parallel scan on the table

    – a_horse_with_no_name
    Nov 15 '18 at 15:09











  • thank you @a_horse_with_no_name , but are you sure ? with different connexion, when creating index with 'concurrently', I see that one index is being creating, and others are 'waiting' (wait_evt_typ = lock // wait_evt = relation)

    – Enialis
    Jan 16 at 11:51








2




2





create index concurrently ... will allow you to create all indexes at the same time (if issued from different connections)

– a_horse_with_no_name
Nov 15 '18 at 15:07






create index concurrently ... will allow you to create all indexes at the same time (if issued from different connections)

– a_horse_with_no_name
Nov 15 '18 at 15:07





1




1





Postgres 11 improved the time it takes to create the index as it can use a parallel scan on the table

– a_horse_with_no_name
Nov 15 '18 at 15:09





Postgres 11 improved the time it takes to create the index as it can use a parallel scan on the table

– a_horse_with_no_name
Nov 15 '18 at 15:09













thank you @a_horse_with_no_name , but are you sure ? with different connexion, when creating index with 'concurrently', I see that one index is being creating, and others are 'waiting' (wait_evt_typ = lock // wait_evt = relation)

– Enialis
Jan 16 at 11:51






thank you @a_horse_with_no_name , but are you sure ? with different connexion, when creating index with 'concurrently', I see that one index is being creating, and others are 'waiting' (wait_evt_typ = lock // wait_evt = relation)

– Enialis
Jan 16 at 11:51













0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322231%2fpostgresql-optimizing-creation-of-several-indexes-on-one-big-table%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322231%2fpostgresql-optimizing-creation-of-several-indexes-on-one-big-table%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Top Tejano songwriter Luis Silva dead of heart attack at 64

政党

天津地下鉄3号線