Re: TB-sized databases
От | Tom Lane |
---|---|
Тема | Re: TB-sized databases |
Дата | |
Msg-id | 15753.1196957598@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: TB-sized databases (Michael Stone <mstone+postgres@mathom.us>) |
Ответы |
Re: TB-sized databases
Re: TB-sized databases Re: TB-sized databases |
Список | pgsql-performance |
Michael Stone <mstone+postgres@mathom.us> writes: > OTOH, the planner can really screw up queries on really large databases. > IIRC, the planner can use things like unique constraints to get some > idea, e.g., of how many rows will result from a join. Unfortunately, > the planner can't apply those techniques to certain constructs common in > really large db's (e.g., partitioned tables--how do you do a unique > constraint on a partitioned table?) I've got some queries that the > planner thinks will return on the order of 10^30 rows for that sort of > reason. In practice, the query may return 10^3 rows, and the difference > between the seq scan and the index scan is the difference between a > query that takes a few seconds and a query that I will never run to > completion. I know the goal would be to make the planner understand > those queries better, Indeed, and if you've got examples where it's that far off, you should report them. regards, tom lane
В списке pgsql-performance по дате отправления: