Re: PostgreSQL 11 higher Planning time on Partitioned table

2020-02-24 Thread Ravi Garg
> IF txnid is real UUID , then you can test the > https://www.postgresql.org/docs/11/datatype-uuid.html performance> see > https://stackoverflow.com/questions/29880083/postgresql-uuid-type-performance> > imho: it should be better. Sure, thanks Imre Thanks and Regards, Ravi Garg On Sunday,

Re: PostgreSQL 11 higher Planning time on Partitioned table

2020-02-24 Thread Ravi Garg
Hi Justin, >I didn't hear how large the tables and indexes >are.+---+--++| >              table_name                   | pg_relation_size |  >pg_total_relation_size - pg_relation_size >|+-

Re: PostgreSQL 11 higher Planning time on Partitioned table

2020-02-23 Thread Imre Samu
> ... txid character varying(36) NOT NULL, > ... WHERE txnid = 'febd139d-1b7f-4564-a004-1b3474e51756' > There is only one index (unique index btree) on 'txnID' (i.e. transaction ID) character varying(36). Which we are creating on each partition. IF txnid is real UUID , then you can test the https

Re: PostgreSQL 11 higher Planning time on Partitioned table

2020-02-23 Thread Justin Pryzby
On Sun, Feb 23, 2020 at 10:57:29AM +, Ravi Garg wrote: >- Currently we are thinking to have Daily partitions and as we need to > keep 6 months of data thus 180 Partitions.However we have liberty to reduce > the number of partitions to weekly/fortnightly/monthly, If we get comparable > pe

Re: PostgreSQL 11 higher Planning time on Partitioned table

2020-02-23 Thread Ravi Garg
Hi Justin, Thanks for response. Unfortunately we will not be able to migrate to PG12 any time soon. - There is only one index (unique index btree) on 'txnID' (i.e. transaction ID) character varying(36). Which we are creating on each partition. - Our use case is limited to simple selects (

Re: PostgreSQL 11 higher Planning time on Partitioned table

2020-02-23 Thread Justin Pryzby
On Sun, Feb 23, 2020 at 04:12:09AM -0600, Justin Pryzby wrote: > How large are the partitions and how many indexes each, and how large are > they? > Each partition will be stat()ed ... for every query. I should have said that's every 1GB "segment" is stat()ed for every query. > This was resolved

Re: PostgreSQL 11 higher Planning time on Partitioned table

2020-02-23 Thread Justin Pryzby
On Sun, Feb 23, 2020 at 09:56:30AM +, Ravi Garg wrote: > Hi, > I am looking to Range Partition one of my table (i.e. TransactionLog) in > PostgreSQL 11.While evaluating query performance difference between the > un-partitioned and partitioned table I am getting huge difference in planning >