Rob Nagler [EMAIL PROTECTED] writes:
Are there plans for explicit hints to the planner?
Personally, I'm philosophically opposed to planner hints; see previous
discussions in the archives.
regards, tom lane
---(end of
Ron Johnson [EMAIL PROTECTED] writes:
How about (if you don't already do it) ranked (or approximately
ranked) b-tree indexes, where each node also stores the (approximate)
count of tuple pointers under it?
This way, the planner would know whether or how skewed a tree is,
and (approximately)
Rob Nagler [EMAIL PROTECTED] writes:
I'm trying to understand how I can get the planner to always do the
right thing with this query:
SELECT
aa_t.min_date_time
FROM
aa_t
, bb_t
, cc_t
WHERE bb_t.bb_id = aa_t.bb_id
AND aa_t.realm_id =
Tom Lane writes:
The reason the planner does not much like this plan is that it's
estimating that quite a lot of rows will have to be hit in min_date_time
order before it finds enough rows with server_id = 21. Thus the high
cost estimate for the above step.
Thanks for the speedy and useful
On Sat, 2003-08-30 at 10:47, Rob Nagler wrote:
Tom Lane writes:
[snip]
enough. When I add this index, I will slow down inserts (about
20K/day) and increase data size (this is the second largest table in
[snip]
Since I gather that this is a web-site, can we presume that they
are clumped into
Tom Lane writes:
That doesn't really tell me anything. What's the proportion of 21
records out of the total table?
Currently we have about 15 servers so 6% of the data is uniformly
distributed with the value 21.
create index fooi on foo (min_date_time) where server_id = 21;
This
On Sat, 2003-08-30 at 15:42, Rob Nagler wrote:
[snip]
We actually have been quite pleased with Postgres's performance
without paying much attention to it before this. When we first set up
Oracle, we got into all of its parameters pretty heavily. With
Postgres, we just tried it and it worked.
