From: Tom Lane
Sent: Friday, January 25, 2019 3:04:37 PM
To: [email protected]
Cc: [email protected]
Subject: Re: Zero throughput on a query on a very large table.
"[email protected]" writes:
> Second, here is what i found and what messed us up.
>
"[email protected]" writes:
> Second, here is what i found and what messed us up.
> select current_setting('random_page_cost'); --> 4
> alter database "CMS_TMP" set random_page_cost=0.0001;
> select current_setting('random_page_cost'); --> 4
ALTER DATABASE only affects
here?
Thank you,
Laurent.
From: [email protected]
Sent: Friday, January 25, 2019 2:06:54 PM
To: Tom Lane
Cc: [email protected]
Subject: Re: Zero throughput on a query on a very large table.
OK... I think we may have cracked this.
First, d
nsaction. I have to change it globally which i
would prefer not to do. Any help here?
Thanks,
Laurent.
____
From: [email protected]
Sent: Friday, January 25, 2019 1:36:21 PM
To: Tom Lane
Cc: [email protected]
Subject: Re: Zero throughput on a qu
@postgresql.org
Subject: Re: Zero throughput on a query on a very large table.
"[email protected]" writes:
> Also, the original statement i implemented did not have all of that. This is
> the normalized SQL that Postgres now gives when looking at the indices.
[ squint...
"[email protected]" writes:
> Also, the original statement i implemented did not have all of that. This is
> the normalized SQL that Postgres now gives when looking at the indices.
[ squint... ] What do you mean exactly by "Postgres gives that"?
I don't see any redundant COLLATE clauses i
org
Subject: Re: Zero throughput on a query on a very large table.
"[email protected]" writes:
> The indices are defined as:
> CREATE INDEX i_outprev_ptclaim
> ON public.tmp_outpatient_rev USING btree
> (desy_sort_key COLLATE pg_catalog."default
ane
Cc: [email protected]; [email protected]
Subject: Re: Zero throughput on a query on a very large table.
On Fri, 25 Jan 2019 at 19:24, Tom Lane wrote:
> PS: On the third hand, you mention having created new indexes on this
> table with apparently not a lot of pain, which is
"[email protected]" writes:
> The indices are defined as:
> CREATE INDEX i_outprev_ptclaim
> ON public.tmp_outpatient_rev USING btree
> (desy_sort_key COLLATE pg_catalog."default", claim_no COLLATE
> pg_catalog."default")
> TABLESPACE pg_default;
> CREATE UNIQUE INDEX ui_outpr
(a few secs).
From: Tom Lane
Sent: Friday, January 25, 2019 1:24:45 AM
To: [email protected]
Cc: [email protected]
Subject: Re: Zero throughput on a query on a very large table.
"[email protected]" writes:
> Query:
>
> -Original Message-
> From: Andreas Kretschmer
> Sent: Friday, January 25, 2019 00:55
> To: [email protected]
> Subject: Re: Zero throughput on a query on a very large table.
>
>
>
> Am 25.01.19 um 06:20 schrieb [email protected]
On Fri, 25 Jan 2019 at 19:24, Tom Lane wrote:
> PS: On the third hand, you mention having created new indexes on this
> table with apparently not a lot of pain, which is a tad surprising
> if you don't have the patience to wait for a sort to finish. How
> long did those index builds take?
It wou
"[email protected]" writes:
> Query:
> select * from tmp_outpatient_rev order by desy_sort_key, claim_no
> Plan:
> [ seqscan-and-sort ... parallelized, but still seqscan-and-sort ]
> - I have tried to hack the planner to force an index scan (which would
> avoid the sort/gather st
Am 25.01.19 um 06:20 schrieb [email protected]:
Hello,
We have been stuck for the past week on a query that simply won’t
“execute”. We have a table with 1.2B rows that took around 14h to
load, but a simple select takes forever and after 10h, no records are
coming through still.
En
Hello,
We have been stuck for the past week on a query that simply won’t “execute”. We
have a table with 1.2B rows that took around 14h to load, but a simple select
takes forever and after 10h, no records are coming through still.
Environment:
- Table tmp_outpatient_rev with 41 VARCHA
15 matches
Mail list logo
