On Tue, Mar 22, 2011 at 01:02, Tom Lane t...@sss.pgh.pa.us wrote:
I studied the code some more, and I think this probably can be made to
work. The basic idea is to have preprocess_minmax_aggregates build
simplified queries like the above (working by modifying the query tree
that exists at the
Hi list,
When I have fields with lots of null values, I often create indexes
like this: CREATE INDEX foo_i ON foo(i) WHERE i IS NOT NULL;
This saves me some space, as most indexed queries exclude NULLs anyway.
In PostgreSQL 9.0.3, min(i) can successfully use this index:
---
marti=#
On Mon, Mar 21, 2011 at 7:17 AM, Marti Raudsepp ma...@juffo.org wrote:
Hi list,
When I have fields with lots of null values, I often create indexes
like this: CREATE INDEX foo_i ON foo(i) WHERE i IS NOT NULL;
This saves me some space, as most indexed queries exclude NULLs anyway.
In
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 21, 2011 at 7:17 AM, Marti Raudsepp ma...@juffo.org wrote:
I know that the Merge Append patch required some changes in the
min/max optimization, which is probably the cause.
Yeah, I think this is a direct result of commit
On Mon, Mar 21, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 21, 2011 at 7:17 AM, Marti Raudsepp ma...@juffo.org wrote:
I know that the Merge Append patch required some changes in the
min/max optimization, which is probably the
Robert Haas wrote:
Tom Lane wrote:
I don't think that suppressing nulls from an index this way is
really very useful. Using a partial index probably eats more
planner cycles than you'll save, overall.
If only 1% of the table has non-NULL values in that column, maybe
not.
We
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas wrote:
Tom Lane wrote:
I don't think that suppressing nulls from an index this way is
really very useful. Using a partial index probably eats more
planner cycles than you'll save, overall.
If only 1% of the table has non-NULL
Greg Stark gsst...@mit.edu writes:
So it's a clever hack that we used to allow the partial indexes to be
used. It relied on the implicit assumption that min(x) and max(x)
where the only values of x where NULL were both NULL.
It would be nice if we were clever enough to support *any* strict
Greg Stark gsst...@mit.edu writes:
On Mon, Mar 21, 2011 at 5:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
For general aggregates, you
have to scan the table anyway. If an index is useful for that, it'll
get picked up in the normal planning process.
if I do SELECT count(col) from tab with no
I wrote:
Hmm. We could possibly fix this by having planagg.c do a completely
separate planner run for each aggregate, wherein it actually does build
the equivalent query
SELECT col FROM tab WHERE existing-quals AND col IS NOT NULL
ORDER BY col ASC/DESC LIMIT 1
and plan that.
Greg Stark gsst...@mit.edu writes:
On Tue, Mar 22, 2011 at 4:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Reimplement planner's handling of MIN/MAX aggregate optimization (again).
I'm just curious, Why is this no longer an interesting special case?
--- this is an interesting special case as of
11 matches
Mail list logo
