Re: [PERFORM] query slow; strace output worrisome

2010-04-05 Thread Craig Ringer
Brian Cox wrote: > On 04/05/2010 09:53 PM, Craig Ringer [cr...@postnewspapers.com.au] wrote: >> Anything in `dmesg' (command) or /var/log/syslog ? > nothing out of the ordinary. Brian I'm wondering if the issue is with strace rather than Pg. That is to say, that strace is trying to print: creat(

Re: [PERFORM] query slow; strace output worrisome

2010-04-05 Thread Brian Cox
On 04/05/2010 09:53 PM, Craig Ringer [cr...@postnewspapers.com.au] wrote: Anything in `dmesg' (command) or /var/log/syslog ? nothing out of the ordinary. Brian -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgres

Re: [PERFORM] query slow; strace output worrisome

2010-04-05 Thread Craig Ringer
On 6/04/2010 9:01 AM, Brian Cox wrote: The SELECT show below has been running for 30+mins and the strace output is alarming: [r...@dione ~]# strace -p 10083 Process 10083 attached - interrupt to quit creat(umovestr: Input/output error 0x2, 0377) = 1025220608 creat(umovestr: Input/output

[PERFORM] query slow; strace output worrisome

2010-04-05 Thread Brian Cox
The SELECT show below has been running for 30+mins and the strace output is alarming: [r...@dione ~]# strace -p 10083 Process 10083 attached - interrupt to quit creat(umovestr: Input/output error 0x2, 0377)= 1025220608 creat(umovestr: Input/output error 0x2, 0377)

Re: [PERFORM] Huge table searching optimization

2010-04-05 Thread Oliver Kindernay
Thanks to all, now it is 0.061 ms :) 2010/4/5 Tom Lane : > Andres Freund writes: >> On Monday 05 April 2010 16:28:35 Oliver Kindernay wrote: >>> i am using this request: >>> select url from test2 where url ~* '^URLVALUE\\s*$'; > >> Depending on your locale it might be sensible to create a text_pa

Re: [PERFORM] How to fast the REINDEX

2010-04-05 Thread Robert Haas
On Thu, Apr 1, 2010 at 9:47 AM, raghavendra t wrote: > and deletes. We also has the weekly maintance of VACUUM, but still reindex > takes lot of time. If you only VACUUM once a week, *everything* is going to take a lot of time. ...Robert -- Sent via pgsql-performance mailing list (pgsql-perfor

Re: [PERFORM] Huge table searching optimization

2010-04-05 Thread Tom Lane
Andres Freund writes: > On Monday 05 April 2010 16:28:35 Oliver Kindernay wrote: >> i am using this request: >> select url from test2 where url ~* '^URLVALUE\\s*$'; > Depending on your locale it might be sensible to create a text_pattern_ops > index - see the following link: > http://www.postgr

Re: [PERFORM] Huge table searching optimization

2010-04-05 Thread Andres Freund
Hi, On Monday 05 April 2010 16:28:35 Oliver Kindernay wrote: > Hi, I have table with just on column named url (it's not real url, > just random string for testing purposes), type text. I have lots of > entries in it (it's dynamic, i add and remove them on the fly), 100 > 000 and more. I've created

Re: [PERFORM] Using high speed swap to improve performance?

2010-04-05 Thread Greg Smith
Christiaan Willemsen wrote: So I was thinking: Why not make a big fat array using 14 disks (raid 1, 10 or 5), and make this a big and fast swap disk. Latency will be lower than the SAN can provide, and throughput will also be better, and it will relief the SAN from a lot of read iops. Pre

Re: [PERFORM] Huge table searching optimization

2010-04-05 Thread hubert depesz lubaczewski
On Mon, Apr 05, 2010 at 04:28:35PM +0200, Oliver Kindernay wrote: > Hi, I have table with just on column named url (it's not real url, > just random string for testing purposes), type text. I have lots of > entries in it (it's dynamic, i add and remove them on the fly), 100 > 000 and more. I've cre

[PERFORM] Huge table searching optimization

2010-04-05 Thread Oliver Kindernay
Hi, I have table with just on column named url (it's not real url, just random string for testing purposes), type text. I have lots of entries in it (it's dynamic, i add and remove them on the fly), 100 000 and more. I've created index on this table to optimize "searching". I just want to test if s

Re: [PERFORM] temp table "on commit delete rows": transaction overhead

2010-04-05 Thread Bruce Momjian
Artiom Makarov wrote: > 2010/4/1 Bruce Momjian : > > > I think one of the problems is that we do the truncate even if the table > > has not be touched by the query, which is poor behavior. > > Thank you for the support. > Will be this problem registered? I have it on my personal TODO and will tr