postgresql-performance

问题 I have a (possibly) basic question about how Postgres executes queries containing WITH clauses. I'm wondering whether including extraneous tables in a WITH clause actually slows down the query. That is, if the "temporary" table created in a WITH clause is never called outside of a WITH clause, is that "temporary" table actually created? In the first example, I am joining two "temporary" tables created using WITH clauses: --Example 1 WITH temp1 as ( SELECT * from table_1 ), temp2 as ( select *

问题 I am writing a function in PostgreSQL. It does basically 3 steps: Fetch a record from source table. check the value from the fetched record in target table, if record is found in target table then update all values of target table with fetched record otherwise insert fetched record to target table. Instead of doing this looping, if I write single query for insert/update, will it be faster than above mentioned approach? How can I achieve same result by writing single query instead looping

问题 In my PostgreSQL 9.6.2 database, I've got a query that builds a table of calculated fields from some stock data. It calculates a moving average window of 1 through 10 years for each row in the table, and uses that in cyclical adjustments. CAPE, CAPB, CAPC, CAPS, and CAPD, specifically. I.e., for each row, you calculate avg(earnings) for the past 1 through 10 years, then do the same for several other variables. I'm currently using a lateral join to compute the aggregates for each row, but

问题 I have a table which has an index on (column A, column B). And I'm running a query that looks like this: SELECT * FROM table WHERE (A, B) IN ((a_1, b_1), (a_2, b_2), ..., (a_5000, b_5000)) This query is very slow ! The plan looks like: Bitmap Heap Scan on table Recheck Cond: (((A = a_1) AND (B = b_1)) OR ((A = a_2) AND (B = b_2)) OR ... -> BitmapOr -> Bitmap Index Scan on idx Index Cond: ((A = a_1) AND (B = b_1)) -> Bitmap Index Scan on idx Index Cond: ((A = a_2) AND (B = b_2)) ...(5000 other

问题 I've got a PostgreSQL table called queries_query , which has many columns. Two of these columns, created and user_sid , are frequently used together in SQL queries by my application to determine how many queries a given user has done over the past 30 days. It is very, very rare that I query these stats for any time older than the most recent 30 days. Here is my question: I've currently created my multi-column index on these two columns by running: CREATE INDEX CONCURRENTLY some_index_name ON

问题 Why is the table "events_201504" included in the query plan below? Based on my query and the check constraint on that table I would expect the query planner to be able to prune it entirely: database=# \d events_201504 Table "public.events_201504" Column | Type | Modifiers ---------------+-----------------------------+--------------------------------------------------------------- id | bigint | not null default nextval('events_id_seq'::regclass) created_at | timestamp without time zone |

问题 Despite what all the documentation says, I'm finding GIN indexes to be significantly slower than GIST indexes for pg_trgm related searches. This is on a table of 25 million rows with a relatively short text field (average length of 21 characters). Most of the rows of text are addresses of the form "123 Main st, City". GIST index takes about 4 seconds with a search like select suggestion from search_suggestions where suggestion % 'seattle'; But GIN takes 90 seconds and the following result

问题 I have a large table: CREATE TABLE "orders" ( "id" serial NOT NULL, "person_id" int4, "created" int4, CONSTRAINT "orders_pkey" PRIMARY KEY ("id") ); 90% of all requests are about orders from the last 2-3 days by a person_id , like: select * from orders where person_id = 1 and created >= extract(epoch from current_timestamp)::int - 60 * 60 * 24 * 3; How can I improve performance? I know about Partitioning, but what about existing rows? And it looks like I need to create INHERITS tables

问题 I'm trying to use ST_SnapToGrid and then GROUP BY the grid cells (x, y). Here is what I did first: SELECT COUNT(*) AS n, ST_X(ST_SnapToGrid(geom, 50)) AS x, ST_Y(ST_SnapToGrid(geom, 50)) AS y FROM points GROUP BY x, y I don't want to recompute ST_SnapToGrid for both x and y . So I changed it to use a sub-query: SELECT COUNT(*) AS n, ST_X(geom) AS x, ST_Y(geom) AS y FROM ( SELECT ST_SnapToGrid(geom, 50) AS geom FROM points ) AS tmp GROUP BY x, y But when I run EXPLAIN , both of these queries

问题 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