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
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:
>
> >
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
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
On 23/12/13 21:58, Johann Spies wrote:
On 19 December 2013 16:48, Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us wrote:
Johann Spies johann.sp...@gmail.com
mailto:johann.sp...@gmail.com writes:
I would appreciate some help optimising the following query:
It's a
On 19 December 2013 16:48, Tom Lane t...@sss.pgh.pa.us wrote:
Johann Spies 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 help much with
a join of this size. Hash or merge join is going to be 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',
Johann Spies 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 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
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,
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
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 veri
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-#
12 matches
Mail list logo