postgresql-performance

I have a big report table. Bitmap Heap Scan step take more than 5 sec. Is there something that I can do? I add columns to the table, does reindex the index that it use will help? I do union and sum on the data, so I don't return 500K records to the client. I use postgres 9.1. Here the explain: Bitmap Heap Scan on foo_table (cost=24747.45..1339408.81 rows=473986 width=116) (actual time=422.210..5918.037 rows=495747 loops=1) Recheck Cond: ((foo_id = 72) AND (date >= '2013-04-04 00:00:00'::timestamp without time zone) AND (date <= '2013-05-05 00:00:00'::timestamp without time zone)) Filter: ((foo

I have two tables, conttagtable (t) and contfloattable (cf). T has about 43k rows. CF has over 9 billion. I created an index on both tables on the tagindex column on both tables. This column can be thought of as a unique identifier for conttagtable and as a foreign key into conttagtable for confloattable . I didn't explicitly create a PK or foreign key on either table relating to the other, although this data is logically related by the tagindex column on both tables as if conttagtable.tagindex were a PRIMARY KEY and contfloattable.tagindex where a FOREIGN KEY (tagindex) REFERENCES

I have database with few hundred millions of rows. I'm running the following query: select * from "Payments" as p inner join "PaymentOrders" as po on po."Id" = p."PaymentOrderId" inner join "Users" as u On u."Id" = po."UserId" INNER JOIN "Roles" as r on u."RoleId" = r."Id" Where r."Name" = 'Moses' LIMIT 1000 When the where clause finds a match in database, I get the result in several milliseconds, but if I modify the query and specify a non-existent r."Name" in where clause, it takes too much time to complete. I guess that PostgreSQL is doing a sequential scan on the Payments table (which

Any ideas how to speed up this query? Input EXPLAIN SELECT entityid FROM entity e LEFT JOIN level1entity l1 ON l1.level1id = e.level1_level1id LEFT JOIN level2entity l2 ON l2.level2id = l1.level2_level2id WHERE l2.userid = 'a987c246-65e5-48f6-9d2d-a7bcb6284c8f' AND (entityid NOT IN (1377776,1377792,1377793,1377794,1377795,1377796... 50000 ids) ) Output Nested Loop (cost=0.00..1452373.79 rows=3865 width=8) -> Nested Loop (cost=0.00..8.58 rows=1 width=8) Join Filter: (l1.level2_level2id = l2.level2id) -> Seq Scan on level2entity l2 (cost=0.00..3.17 rows=1 width=8) Filter: ((userid)::text =

I'm having trouble regarding speed in a SELECT query on a Postgres database. I have a table with two integer columns as key: (int1,int2) This table has around 70 million rows. I need to make two kind of simple SELECT queries in this environment: SELECT * FROM table WHERE int1=X; SELECT * FROM table WHERE int2=X; These two selects returns around 10.000 rows each out of these 70 million. For this to work as fast as possible I thought on using two HASH indexes, one for each column. Unfortunately the results are not that good: QUERY PLAN ------------------------------------------------------------

I have three tables in my app, call them tableA , tableB , and tableC . tableA has fields for tableB_id and tableC_id , with indexes on both. tableB has a field foo with an index, and tableC has a field bar with an index. When I do the following query: select * from tableA left outer join tableB on tableB.id = tableA.tableB_id where lower(tableB.foo) = lower(my_input) it is really slow (~1 second). When I do the following query: select * from tableA left outer join tableC on tableC.id = tabelA.tableC_id where lower(tableC.bar) = lower(my_input) it is really fast (~20 ms). From what I can tell,

I'm trying to fetch most recent row in a table. I have a simple timestamp created_at which is indexed. When I query ORDER BY created_at DESC LIMIT 1 , it takes far more than I think it should (about 50ms on my machine on 36k rows). EXPLAIN -ing claims that it uses backwards index scan , but I confirmed that changing the index to be (created_at DESC) does not change the cost in query planner for a simple index scan . How can I optimize this use case? Running postgresql 9.2.4 . Edit: # EXPLAIN SELECT * FROM articles ORDER BY created_at DESC LIMIT 1; QUERY PLAN -----------------------------------

I have this PostgreSQL 9.4 query that runs very fast (~12ms): SELECT auth_web_events.id, auth_web_events.time_stamp, auth_web_events.description, auth_web_events.origin, auth_user.email, customers.name, auth_web_events.client_ip FROM public.auth_web_events, public.auth_user, public.customers WHERE auth_web_events.user_id_fk = auth_user.id AND auth_user.customer_id_fk = customers.id AND auth_web_events.user_id_fk = 2 ORDER BY auth_web_events.id DESC; But if I embed it into a function, the query runs very slow through all data, seems that is running through every record, what am I missing?, I

I have this process that has to make a series of queries, using pl/pgsql: --process: SELECT function1(); SELECT function2(); SELECT function3(); SELECT function4(); To be able to execute everything in one call, I created a process function as such: CREATE OR REPLACE FUNCTION process() RETURNS text AS $BODY$ BEGIN PERFORM function1(); PERFORM function2(); PERFORM function3(); PERFORM function4(); RETURN 'process ended'; END; $BODY$ LANGUAGE plpgsql The problem is, when I sum the time that each function takes by itself, the total is 200 seconds, while the time that the function process() takes