On Wed, Oct 10, 2012 at 9:13 PM, Korisk wrote:
>-> Index Only Scan Backward using hashcheck_name_idx on public.hashcheck
> (cost=100.00..1398674.92 rows=25986792 width=32)
It seems odd.
Is it possible to look at the non default configuration?
SELECT name, setting, reset_val F
On Wed, Oct 10, 2012 at 11:42 PM, Scott Marlowe wrote:
> On Wed, Oct 10, 2012 at 11:26 PM, Craig Ringer wrote:
>> On 10/11/2012 01:06 AM, Franck Routier wrote:
>>>
>>> Hi,
>>>
>>> I have pretty large tables, with columns that might never receive any
>>> data, or always receive data, based on the
On Wed, Oct 10, 2012 at 11:26 PM, Craig Ringer wrote:
> On 10/11/2012 01:06 AM, Franck Routier wrote:
>>
>> Hi,
>>
>> I have pretty large tables, with columns that might never receive any
>> data, or always receive data, based on the customer needs.
>> The index on these columns are really big, ev
On Wed, Oct 10, 2012 at 4:37 PM, Claudio Freire wrote:
> On Wed, Oct 10, 2012 at 7:33 PM, Jeff Janes wrote:
>>> Well, the real question is whether, while traversing the index, if some
>>> of the pages are going to be removed from the cache by other process
>>> cache usage. effective_cache_size i
On 10/11/2012 01:06 AM, Franck Routier wrote:
Hi,
I have pretty large tables, with columns that might never receive any
data, or always receive data, based on the customer needs.
The index on these columns are really big, even if the column is never
used, so I tend to add a "where col is not n
On 10/11/2012 12:13 PM, Korisk wrote:
Thanx for the advice, but increment table is not acceptable because it should
be a plenty of them.
Nevertheless in the investigations was achieved some progress (7.4 sec vs 19.6
sec).
But using IOS scan
"IOS scan" ?
Do you mean some kind of I/O monitorin
Thanx for the advice, but increment table is not acceptable because it should
be a plenty of them.
Nevertheless in the investigations was achieved some progress (7.4 sec vs 19.6
sec).
But using IOS scan you can see that there is an abnormal cost calculations it
make me suspicious of little bug
On Wed, Oct 10, 2012 at 7:33 PM, Jeff Janes wrote:
>> Well, the real question is whether, while traversing the index, if some
>> of the pages are going to be removed from the cache by other process
>> cache usage. effective_cache_size is not figuring the cache will remain
>> between queries.
>
>
On Wed, Oct 10, 2012 at 2:03 PM, Bruce Momjian wrote:
> On Wed, Oct 10, 2012 at 10:12:51PM +0200, Strahinja Kustudić wrote:
>> @Claudio So you are basically saying that if I have set effective_cache_size
>> to
>> 10GB and I have 10 concurrent processes which are using 10 different indices
>> whi
On Wed, Oct 10, 2012 at 7:06 PM, Ondrej Ivanič wrote:
>> Generally going over 4GB for shared_buffers doesn't help.. some of the
>> overhead of bgwriter and checkpoints is more or less linear in the size of
>> shared_buffers ..
>
> Nothing is black or white; It's all shades of Grey :) It depends on
Hi,
On 10 October 2012 19:11, Julien Cigar wrote:
>> shared_buffers = 10GB
>
>
> Generally going over 4GB for shared_buffers doesn't help.. some of the
> overhead of bgwriter and checkpoints is more or less linear in the size of
> shared_buffers ..
Nothing is black or white; It's all shades of G
On Wed, Oct 10, 2012 at 9:09 AM, Korisk wrote:
> Hello! Is it possible to speed up the plan?
> Sort (cost=573977.88..573978.38 rows=200 width=32) (actual
> time=10351.280..10351.551 rows=4000 loops=1)
>Output: name, (count(name))
>Sort Key: hashcheck.name
>Sort Method: quicksort Me
On Wed, Oct 10, 2012 at 10:12:51PM +0200, Strahinja Kustudić wrote:
> @Bruce Thanks for your articles, after reading them all I don't think
> disabling
> swap is a good idea now. Also you said to see the effective_cache_size I
> should
> check it with free. My question is should I use the value t
On Wed, Oct 10, 2012 at 5:12 PM, Strahinja Kustudić
wrote:
> @Claudio So you are basically saying that if I have set effective_cache_size
> to 10GB and I have 10 concurrent processes which are using 10 different
> indices which are for example 2GB, it would be better to set the
> effective_cache s
@Bruce Thanks for your articles, after reading them all I don't think
disabling swap is a good idea now. Also you said to see the
effective_cache_size I should check it with free. My question is should I
use the value that free is showing as cached, or a little lower one, since
not everything in th
On Wed, Oct 10, 2012 at 12:12 AM, Strahinja Kustudić
wrote:
> Hi everyone,
>
> I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM and RAID10
> 15K SCSI drives which is runing Centos 6.2 x64.
How many drives in the RAID?
> This server is mainly used
> for inserting/updating large am
On 10/10/2012 08:59 AM, Oleg Bartunov wrote:
We'll present in Prague some improvements in FTS. Unfortunately, we have
only several minutes during lighting talk. In short, we improved GIN to
store additional information, coordinates for fts, for example and
return ordered by rank search results, w
On 10/10/2012 06:38 AM, François Beausoleil wrote:
Notice the ts_rank() is on the outer query, which means it'll only
run on the subset of documents which match the query. This is
explicitly mentioned in the docs:
"""Ranking can be expensive since it requires consulting the tsvector
of each matc
On Wed, Oct 10, 2012 at 3:18 PM, Shaun Thomas wrote:
>> Why does nobody every mention that concurrent access has to be taken
>> into account?
>
>
> That's actually a good point. But if you have one giant database, the
> overlap of which tables are being accessed by various sessions is going to
> b
On 10/10/2012 12:05 PM, Claudio Freire wrote:
Why does nobody every mention that concurrent access has to be taken
into account?
That's actually a good point. But if you have one giant database, the
overlap of which tables are being accessed by various sessions is going
to be immense.
Ther
On Wed, Oct 10, 2012 at 11:44 AM, Claudio Freire wrote:
> On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas
> wrote:
>> On 10/09/2012 06:30 PM, Craig James wrote:
>>
>>>ra:8192 walb:1M ra:256 walb:1Mra:256 walb:256kB
>>> --
On Wed, Oct 10, 2012 at 02:05:20PM -0300, Claudio Freire wrote:
> On Wed, Oct 10, 2012 at 1:10 PM, Bruce Momjian wrote:
> >> >shared_buffers = 10GB
> >>
> >> Generally going over 4GB for shared_buffers doesn't help.. some of
> >> the overhead of bgwriter and checkpoints is more or less linear in
>
Hi,
I have pretty large tables, with columns that might never receive any
data, or always receive data, based on the customer needs.
The index on these columns are really big, even if the column is never
used, so I tend to add a "where col is not null" clause on those indexes.
What are the dr
Sent this to Claudio rather than the whole list ... here it is.
On Wed, Oct 10, 2012 at 7:44 AM, Claudio Freire wrote:
> On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas
> wrote:
> > On 10/09/2012 06:30 PM, Craig James wrote:
> >
> >>ra:8192 walb:1M ra:256 walb:1Mra:256 walb:2
On Wed, Oct 10, 2012 at 1:10 PM, Bruce Momjian wrote:
>> >shared_buffers = 10GB
>>
>> Generally going over 4GB for shared_buffers doesn't help.. some of
>> the overhead of bgwriter and checkpoints is more or less linear in
>> the size of shared_buffers ..
>>
>> >effective_cache_size = 90GB
>>
>> e
On Wed, Oct 10, 2012 at 11:44:50AM -0300, Claudio Freire wrote:
> On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas
> wrote:
> > On 10/09/2012 06:30 PM, Craig James wrote:
> >
> >>ra:8192 walb:1M ra:256 walb:1Mra:256 walb:256kB
> >> -
On Wed, Oct 10, 2012 at 10:11:30AM +0200, Julien Cigar wrote:
> On 10/10/2012 09:12, Strahinja Kustudić wrote:
> >Hi everyone,
>
> Hello,
>
> >
> >I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM
> >and RAID10 15K SCSI drives which is runing Centos 6.2 x64. This
> >server is mainl
Hello! Is it possible to speed up the plan?
hashes=# \d hashcheck
Table "public.hashcheck"
Column | Type| Modifiers
+---+
id
On Wed, Oct 10, 2012 at 09:12:20AM +0200, Strahinja Kustudić wrote:
> Hi everyone,
>
> I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM and RAID10
> 15K
> SCSI drives which is runing Centos 6.2 x64. This server is mainly used for
> inserting/updating large amounts of data via copy
On 10/10/2012 09:35 AM, Strahinja Kustudić wrote:
#sysctl vm.dirty_ratio
vm.dirty_ratio = 40
# sysctl vm.dirty_background_ratio
vm.dirty_background_ratio = 10
Och. That looks a lot like an old RHEL or CentOS system. Change
those ASAP. Currently your system won't start writing dirty buffers
We'll present in Prague some improvements in FTS. Unfortunately, we have
only several minutes during lighting talk. In short, we improved GIN to
store additional information, coordinates for fts, for example and return
ordered by rank search results, which gave us performance better than
sphynx.
On 10/10/2012 09:49 AM, Strahinja Kustudić wrote:
I will change those, but I don't think this is that big of an issue if
most of the IO is done by Postgres, since Postgres has it's own
mechanism to tell the OS to sync the data to disk. For example when it's
writing a wal file, or when it's writi
I will change those, but I don't think this is that big of an issue if most
of the IO is done by Postgres, since Postgres has it's own mechanism to
tell the OS to sync the data to disk. For example when it's writing a wal
file, or when it's writing a check point, those do not get cached.
Regards,
On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas wrote:
> On 10/09/2012 06:30 PM, Craig James wrote:
>
>>ra:8192 walb:1M ra:256 walb:1Mra:256 walb:256kB
>> -
>> -c -tRun1 Run2 Run3 Run4 Run5 Run6 R
Shaun,
running these commands:
#sysctl vm.dirty_ratio
vm.dirty_ratio = 40
# sysctl vm.dirty_background_ratio
vm.dirty_background_ratio = 10
shows that these values are even higher by default. When you said RAID
buffer size, you meant the controllers cache memory size?
Regards,
Strahinja
On We
On 10/10/2012 02:12 AM, Strahinja Kustudić wrote:
totalused free shared buffers cached
Mem: 96730 96418311 071 93120
Wow, look at all that RAM. Something nobody has mentioned yet, you'll
want to set some additional kernel parameters for this
On 10/09/2012 06:30 PM, Craig James wrote:
ra:8192 walb:1M ra:256 walb:1Mra:256 walb:256kB
-
-c -tRun1 Run2 Run3 Run4 Run5 Run6 Run7 Run8 Run9
40 2500 4261 3722 4243 9286 9240 5712
Le 2012-10-09 à 17:38, Shane Hathaway a écrit :
> Hello,
>
> The database has a text index of around 200,000 documents. Investigation
> revealed that text queries are slow only when using ts_rank or ts_rank_cd.
> Without a ts_rank function, any query is answered within 200ms or so; with
> ts
Thanks for your help everyone.
I set:
shared_buffers = 4GB
effective_cache_size = 72GB
work_mem = 128MB
maintenance_work_mem = 4GB
checkpoint_segments = 64
checkpoint_completion_target = 0.9
random_page_cost = 3.5
cpu_tuple_cost = 0.05
Where can I get the values for random_page_cost and for cpu_t
On 10/10/2012 10:30, Strahinja Kustudić wrote:
Thanks for very fast replies everyone :)
@Laurenz I know that effective cache size is only used for the query
planner, what I was saying is that if I tell it that it can have 90GB
cached items, that is not trues, since the OS and Postgres process
Thanks for very fast replies everyone :)
@Laurenz I know that effective cache size is only used for the query
planner, what I was saying is that if I tell it that it can have 90GB
cached items, that is not trues, since the OS and Postgres process itself
can take more than 6GB, which would mean 90G
On 10/10/2012 09:12, Strahinja Kustudić wrote:
Hi everyone,
Hello,
I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM and
RAID10 15K SCSI drives which is runing Centos 6.2 x64. This server is
mainly used for inserting/updating large amounts of data via
copy/insert/update com
Strahinja Kustudic wrote:
>> I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM and RAID10
>> 15K SCSI drives
>> which is runing Centos 6.2 x64. This server is mainly used for
>> inserting/updating large amounts of
>> data via copy/insert/update commands, and seldom for running sele
On 10.10.2012 09:12, Strahinja Kustudić wrote:
> Hi everyone,
>
> I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM and
> RAID10 15K SCSI drives which is runing Centos 6.2 x64. This server is
> mainly used for inserting/updating large amounts of data via
> copy/insert/update command
Hm, I just notices that shared_buffers + effective_cache_size = 100 > 96GB,
which can't be right. effective_cache_size should probably be 80GB.
Strahinja Kustudić | System Engineer | Nordeus
On Wed, Oct 10, 2012 at 9:12 AM, Strahinja Kustudić
wrote:
> Hi everyone,
>
> I have a Postgresql 9.1 d
Hi everyone,
I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM and RAID10
15K SCSI drives which is runing Centos 6.2 x64. This server is mainly used
for inserting/updating large amounts of data via copy/insert/update
commands, and seldom for running select queries.
Here are the rel
46 matches
Mail list logo
