From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: TB-sized databases |
Date: | 2007-12-06 16:13:18 |
Message-ID: | 15753.1196957598@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Michael Stone <mstone+postgres(at)mathom(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew | 2007-12-06 17:46:35 | Re: TB-sized databases |
Previous Message | Michael Stone | 2007-12-06 15:42:14 | Re: TB-sized databases |