[PERFORM] Performance problems with DISTINCT ON

2009-09-28 Thread Sgarbossa Domenico
I need to retrieve the most recent prices per products from a price list table: CREATE TABLE listini_anagrafici ( id character varying(36) NOT NULL, articolo character varying(18), listino character varying(5), data_ent date, data_fin date, prezzo double precision, ultimo boolean DE

Re: [PERFORM] Postgres performance

2009-09-28 Thread Scott Marlowe
Didn't see the original message so I replied to this one. On Mon, Sep 28, 2009 at 8:11 AM, Andy Colson wrote: > std pik wrote: >> >> Hi all.. >> please, how can i tune postgres performance? Start here: http://www.westnet.com/~gsmith/content/postgresql/ -- Sent via pgsql-performance mailing lis

Re: [PERFORM] PG 8.3 and large shared buffer settings

2009-09-28 Thread Josh Berkus
On 9/26/09 8:19 AM, Greg Smith wrote: > This means that the question you want an answer to is "if the OS cache > isn't really available, where does giving memory to shared_buffers > becomes less efficient than not caching things at all?" My guess is > that this number is much larger than 10GB, but

Re: [PERFORM] Postgres performance

2009-09-28 Thread Andy Colson
std pik wrote: Hi all.. please, how can i tune postgres performance? Thanks. Thats a very generic question. Here are some generic answers: You can tune the hardware underneath. Faster hardware = faster pg. You can tune the memory usage, and other postgres.conf setting to match your hardwa

Re: [PERFORM] LIMIT confuses the planner (again)

2009-09-28 Thread Robert Haas
On Mon, Sep 28, 2009 at 4:43 AM, Kouber Saparev wrote: > Hello, > > I am using PostgreSQL 8.3.7 and I am experiencing an issue similar to the > one I've already described some time ago: > http://archives.postgresql.org/pgsql-performance/2009-02/msg00261.php > > Again, adding a LIMIT clause to a qu

[PERFORM] LIMIT confuses the planner (again)

2009-09-28 Thread Kouber Saparev
Hello, I am using PostgreSQL 8.3.7 and I am experiencing an issue similar to the one I've already described some time ago: http://archives.postgresql.org/pgsql-performance/2009-02/msg00261.php Again, adding a LIMIT clause to a query, which is normally executing very fast thanks to an index, m