Re: [PERFORM] select with max functions

- Mensaje original - > De: "Mariel Cherkassky" > Para: "Andreas Kretschmer" > CC: pgsql-performance@postgresql.org > Enviados: Lunes, 2 de Octubre 2017 10:25:19 > Asunto: Re: [PERFORM] select with max functions > > Andreas I tried

Re: [PERFORM] select with max functions

- Mensaje original - > De: "Mariel Cherkassky" > Para: pgsql-performance@postgresql.org > Enviados: Domingo, 1 de Octubre 2017 9:41:37 > Asunto: [PERFORM] select with max functions > > Hi, > I need to use the max function in my query. I had very bad

Re: [PERFORM] OS cache management

- Mensaje original - > De: "Soni M" > Para: pgsql-performance@postgresql.org > Enviados: Miércoles, 6 de Septiembre 2017 5:12:26 > Asunto: [PERFORM] OS cache management > > Hello All, I would like to know about how OS cache works for postgres table > and index

Re: [PERFORM]

- Mensaje original - > De: "Yevhenii Kurtov" > Para: pgsql-performance@postgresql.org > Enviados: Miércoles, 28 de Junio 2017 3:47:44 > Asunto: [PERFORM] > > Hello, > > We have a query that is run almost each second and it's very important to > squeeze every

Re: [PERFORM] Slow query with 3 table joins

Some other approaches you could try: 1) What about an hashed index? You could make CREATE INDEX ON FIELD (unit_id, hashtext(field_name)) and changing your query accordingly "where hashtext(FIELD.FIELD_NAME)=hashtext('SHEETS_PRESENT') " 2) Partitioning (not native yet, but can be

Re: [PERFORM] Slow query with 3 table joins

- Mensaje original - > De: "Alessandro Ferrucci" > Para: pgsql-performance@postgresql.org > Enviados: Miércoles, 26 de Abril 2017 0:19:37 > Asunto: Re: [PERFORM] Slow query with 3 table joins > > > > After about 40 inutes the slow query finally finished

Re: [PERFORM] Understanding PostgreSQL query execution time

- Mensaje original - > De: "Haider Ali" > Para: pgsql-performance@postgresql.org > Enviados: Viernes, 7 de Abril 2017 11:56:53 > Asunto: [PERFORM] Understanding PostgreSQL query execution time > > > Hello > > > I want to understand execution time of a query

Re: [PERFORM] Slow query after 9.3 to 9.6 migration

> > Hi there, fellow experts! > > > I need an advice with query that became slower after 9.3 to 9.6 > migration. > > > First of all, I'm from the dev team. > > > Before migration, we (programmers) made some modifications on query > bring it's average time from 8s to 2-3s. > > > As this

Re: [PERFORM] Create language plperlu Error

- Mensaje original - > De: "Om Prakash Jaiswal" > Para: pgsql-performance@postgresql.org, "Pgsql-admin" > , pgsql-b...@postgresql.org > Enviados: Martes, 2 de Agosto 2016 2:47:19 > Asunto: [PERFORM] Create language plperlu Error > > >

Re: [PERFORM] Combination of partial and full indexes

I dont think offers_source_id_o_key_idx will be used at all. It is a UNIQUE index on (source_id, o_key), but your query does not filter for any "o_key", so reading that index does not provide the pointers needed to fetch the actual data in the table. I will try an index on source_id,

Re: [PERFORM] Database transaction with intermittent slow responses

? Gerardo - Mensaje original - > De: "John Gorman" <jgor...@eldocomp.com> > Para: "Gerardo Herzig" <gher...@fmed.uba.ar> > CC: pgsql-performance@postgresql.org, "John Gorman" <jgor...@eldocomp.com> > Enviados: Viernes, 13 de Mayo 2016 1

Re: [PERFORM] Database transaction with intermittent slow responses

After quick reading, im thinking about a couples of chances: 1) You are hitting a connection_limit 2) You are hitting a lock contention (perhaps some other backend is locking the table and not releasing it) Who throws the timeout? It is Postgres or your JDBC connector? My initial blind guess

Re: [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL

Ok, a quick view on the system, and some things that may be important to note: Our deployment machine is a Dell PowerEdge T420 with a Perc H710 RAID controller configured in this way: * VD0: two 15k SAS disks (ext4, OS partition, WAL partition, RAID1) * VD1: ten 10k SAS disks

[PERFORM] performance drop when function argument is evaluated in WHERE clause

Hi all. I have a function that uses a simple select between 3 tables. There is a function argument to help choose how a WHERE clause applies. This is the code section: select * from [...] where case $3 when 'I' then [filter 1] when 'E' then [filter 2] when 'P' then [filter 3] else

Re: [PERFORM] performance drop when function argument is evaluated in WHERE clause

why the optimizer issues, since the arguments are immutable strings, and should (or could at least) be evaluated only once. Thanks again for your time! Gerardo - Mensaje original - De: Tom Lane t...@sss.pgh.pa.us Para: Gerardo Herzig gher...@fmed.uba.ar CC: pgsql-performance