On Tue, Mar 22, 2011 at 01:02, Tom Lane 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 point where it
Greg Stark writes:
> On Tue, Mar 22, 2011 at 4:35 AM, Tom Lane 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 9.1
> -explain (costs off)
>
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 th
Greg Stark writes:
> On Mon, Mar 21, 2011 at 5:40 PM, Tom Lane 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 WHERE clauses on a table
>
Greg Stark 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
> aggregate us
"Kevin Grittner" 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 values in th
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
On Mon, Mar 21, 2011 at 10:25 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 21, 2011 at 7:17 AM, Marti Raudsepp 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
Robert Haas writes:
> On Mon, Mar 21, 2011 at 7:17 AM, Marti Raudsepp 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
> 034967bdcbb0c7be61d0500955226e1234ec5f04.
Yea
On Mon, Mar 21, 2011 at 7:17 AM, Marti Raudsepp 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 PostgreSQL 9.0.3
10 matches
Mail list logo
