On Sun, Mar 27, 2016 at 9:12 AM, Wei Shan wrote:
> Hi Andreas,
>
> The tablespace is not on SSD although I intend to do it within the next
> week. I actually tried reducing the random_page_cost to 0.2 but it doesn't
> help.
Setting random_page_cost to less than seq_page_cost is nonsensical.
You
Hi Andreas,
The tablespace is not on SSD although I intend to do it within the next
week. I actually tried reducing the random_page_cost to 0.2 but it doesn't
help.
On 26 March 2016 at 22:13, Andreas Kretschmer
wrote:
> Wei Shan wrote:
>
> > Hi all,
> >
> > Please provide some advise on the fo
Wei Shan wrote:
> Hi all,
>
> Please provide some advise on the following query not using the index:
> I have 2 questions:
>
> 1. Why does the optimizer chose not to use the index when it will run faster?
because of the estimated costs.:
Seq Scan on testdb auditrecor0_ (cost=0.00..18147465.
Hi all,
Please provide some advise on the following query not using the index:
pgsql version: 9.2.4
OS version: RedHat 6.5
Ram: 64 GB
rows in testdb: 180 million
shared_buffers: 16GB
effective_cache_size: 32GB
work_mem='32MB'
I have executed the query below after I vaccum analyze the table.
I h
On 23/12/13 21:58, Johann Spies wrote:
On 19 December 2013 16:48, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote:
Johann Spies mailto:johann.sp...@gmail.com>> writes:
> I would appreciate some help optimising the following query:
It's a mistake to imagine that indexes are going to h
On 19 December 2013 16:48, Tom Lane wrote:
> Johann Spies writes:
> > I would appreciate some help optimising the following query:
>
> It's a mistake to imagine that indexes are going to help much with
> a join of this size. Hash or merge join is going to be a lot better
> than nestloop. What
Johann Spies writes:
> I would appreciate some help optimising the following query:
It's a mistake to imagine that indexes are going to help much with
a join of this size. Hash or merge join is going to be a lot better
than nestloop. What you need to do is make sure those will perform
as well a
I would appreciate some help optimising the following query:
with
subject_journals as(
select A.sq
fromisi.rissue A,
isi.rsc_joern_link C
WHERE
C.sc_id in
('d0963875-e438-4923-b3fa-f462e8975221',
Hi all,
Thanks for the reply. I made some more test and find out that the
problem is with the <<= operator for the network type. Can I create
index which to work with <<=. Because if I use = the index is used. But
not for <<=.
iplog=# explain analyze SELECT *
iplog-#
Hi all,
Thanks for the reply. I made some more test and find out that the
problem is with the <<= operator for the network type. Can I create
index which to work with <<=. Because if I use = the index is used. But
not for <<=.
iplog=# explain analyze SELECT *
iplog-#
On 12/9/05, Kaloyan Iliev <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have a problem with a query which doeson't want to use indexes. I
> tried to create different indexes but nothing help. Can anyone suggest
> what index I need.
> This query is executed 1.5Milion times per day and I need it to be v
Hi all,
I have a problem with a query which doeson't want to use indexes. I
tried to create different indexes but nothing help. Can anyone suggest
what index I need.
This query is executed 1.5Milion times per day and I need it to be veri
fast. I made my test on 8.0.0 beta but the production da
12 matches
Mail list logo
