[PERFORM] Postgres array parser

2011-12-13 Thread Aleksej Trofimov
Hello, I wanted to ask according such a problem which we had faced with. We are widely using postgres arrays like key->value array by doing like this: {{1,5},{2,6},{3,7}} where 1,2,3 are keys, and 5,6,7 are values. In our pgSql functions we are using self written array_input(array::numeric[],

Re: [PERFORM] Postgres array parser

2011-12-13 Thread Pavel Stehule
Hello do you know FOREACH IN ARRAY statement in 9.1 this significantly accelerate iteration over array http://www.depesz.com/index.php/2011/03/07/waiting-for-9-1-foreach-in-array/ 2011/12/13 Aleksej Trofimov : > Hello, I wanted to ask according such a problem which we had faced with. > We are

Re: [PERFORM] Postgres array parser

2011-12-13 Thread Aleksej Trofimov
We have tried foreach syntax, but we have noticed performance degradation: Function with for: 203ms Function with foreach: ~250ms: there is functions code: CREATE OR REPLACE FUNCTION input_value_fe(in_inputs numeric[], in_input_nr numeric) RETURNS numeric AS $BODY$ declare i numeric[]; BEGIN

Re: [PERFORM] copy vs. C function

2011-12-13 Thread Jon Nelson
On Mon, Dec 12, 2011 at 10:38 AM, Merlin Moncure wrote: > On Sat, Dec 10, 2011 at 7:27 PM, Jon Nelson wrote: >> I was experimenting with a few different methods of taking a line of >> text, parsing it, into a set of fields, and then getting that info >> into a table. >> >> The first method involv

Re: [PERFORM] Postgres array parser

2011-12-13 Thread Pavel Stehule
Hello 2011/12/13 Aleksej Trofimov : > We have tried foreach syntax, but we have noticed performance degradation: > Function with for: 203ms > Function with foreach: ~250ms: > > there is functions code: > CREATE OR REPLACE FUNCTION input_value_fe(in_inputs numeric[], in_input_nr > numeric) >  RETUR

[PERFORM] select distinct uses index scan vs full table scan

2011-12-13 Thread Jon Nelson
I've got a 5GB table with about 12 million rows. Recently, I had to select the distinct values from just one column. The planner chose an index scan. The query took almost an hour. When I forced index scan off, the query took 90 seconds (full table scan). The planner estimated 70,000 unique values

Re: [PERFORM] select distinct uses index scan vs full table scan

2011-12-13 Thread Tom Lane
Jon Nelson writes: > I've got a 5GB table with about 12 million rows. > Recently, I had to select the distinct values from just one column. > The planner chose an index scan. The query took almost an hour. > When I forced index scan off, the query took 90 seconds (full table scan). Usually, we he

Re: [PERFORM] select distinct uses index scan vs full table scan

2011-12-13 Thread Jon Nelson
On Tue, Dec 13, 2011 at 1:57 PM, Tom Lane wrote: > Jon Nelson writes: >> I've got a 5GB table with about 12 million rows. >> Recently, I had to select the distinct values from just one column. >> The planner chose an index scan. The query took almost an hour. >> When I forced index scan off, the

Re: [PERFORM] Slow query after upgrade from 8.2 to 8.4

2011-12-13 Thread Mark Kirkwood
On 10/12/11 04:30, Tom Lane wrote: However, it's not apparent to me why you would see any difference between 8.2 and 8.4 on this type of query. I tried a query analogous to this one on both, and got identical plans. I'm guessing that your slowdown is due to not having updated statistics on the

Re: [PERFORM] copy vs. C function

2011-12-13 Thread Tom Lane
Jon Nelson writes: > The only thing I have left are these statements: > get_call_result_type > TupleDescGetAttInMetadata > BuildTupleFromCStrings > HeapTupleGetDatum > and finally PG_RETURN_DATUM > It turns out that: > get_call_result_type adds 43 seconds [total: 54], > TupleDescGetAttInMetadata

Re: [PERFORM] copy vs. C function

2011-12-13 Thread idc danny
Hi guys, A nub question here since I could not figure it out on my own: I'm using Hamachi to connect different sites into a VPN and their address always starts with 5.*.*.* - the problem I'm facing is that I cannot make the access restricted to that particular range only. Currently I got : host a