Re: [PERFORM] Performance problems with DISTINCT ON

Sgarbossa Domenico wrote: > I need to retrieve the most recent prices per products from a price list > table: > select distinct on (articolo) articolo,data_ent,prezzo from > listini_anagrafici order by articolo, data_ent desc > > but it seems that this query runs slowly... about 5/6 seconds. >

[PERFORM] Using OProfile

Hi, I tried to profile postgresql queries with OProfile but I could not do. OProfile version: 0.9.5 PostgreSQL version: 8.4.0 OS: CentOS 5 I compiled OProfile with "./configure --with-kernel-support", "make" and "make install"; also I created a user and a group both named as "oprofile". User

Re: [PERFORM] Performance problems with DISTINCT ON

Subject: Re: [PERFORM] Performance problems with DISTINCT ON Sgarbossa Domenico wrote: I need to retrieve the most recent prices per products from a price list table: select distinct on (articolo) articolo,data_ent,prezzo from listini_anagrafici order by articolo, data_ent desc but it see

Re: [PERFORM] Performance problems with DISTINCT ON

> Should I try a different approach to solve this issue? Yes. Ask yourself if you *really* need 180k rows. Best regards, depesz -- Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/ jid/gtalk: dep...@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007 -- Sent

Re: [PERFORM] Using OProfile

Reydan Cankur writes: > I tried to profile postgresql queries with OProfile but I could not do. You would be better off asking this of the oprofile people, as I suspect your problem is "oprofile doesn't work at all" not "oprofile doesn't work with postgres". FWIW, oprofile requires kernel suppor

Re: [PERFORM] Performance problems with DISTINCT ON

Distinct on Postgres 8.1 forces a sort. It may be faster if you restructure the query to use a group by + order by. But that might not help either, since the data might not be large enough for a plan that hash aggregates and then sorts the result to be faster. An index on (articolo, data_end des

[PERFORM] FullTextSearch - UNION individual indexes or concatenated columns index ?

I'm attempting to implement full-text search and am torn between two techniques: 1) Create multiple GIN indexes on columns I'm going to search against and UNION the results or 2) Create one concatenated column GIN index consisting of the columns that will be searched. Is there any performance c

Re: [PERFORM] Speed while runnning large transactions.

2009/9/24 : >> On Thu, Sep 24, 2009 at 9:27 AM, wrote: >> >>> Hi. >>> >>> I have a transaction running at the database for around 20 hours .. >>> still >>> isn't done. But during the last hours it has come to the point where it >>> really hurts performance of "other queries". >>> >>> Given pg_sta

Re: [PERFORM] FullTextSearch - UNION individual indexes or concatenated columns index ?

Jeremy, > Is there any performance considerations that may make one technique > better than the other? (2) will me much faster. Assuming you're searching all columns, of course. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-perfor