On Wed, Jun 14, 2006 at 10:36:55PM -0400, Tom Lane wrote:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > On Jun 13, 2006, at 8:50 PM, Tom Lane wrote:
> >> Hmm ... worksforme. Could you provide a complete test case?
>
> > decibel=# create table date_test(d date not null, i int not null);
> > [etc]
>
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Jun 13, 2006, at 8:50 PM, Tom Lane wrote:
>> Hmm ... worksforme. Could you provide a complete test case?
> decibel=# create table date_test(d date not null, i int not null);
> [etc]
Not sure what you are driving at. The estimates are clearly not
defaul
On Jun 13, 2006, at 8:50 PM, Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
On Tue, Jun 13, 2006 at 06:04:42PM -0400, Tom Lane wrote:
It'd depend on the context, possibly, but it's easy to show that the
current planner does fold "now() - interval_constant" when making
estimates. S
>>> On 6/13/2006 at 9:13 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Read what you wrote, and rethink...
Hah. Yes, I understand the irony of that statement, but the point is
that the value of the variable won't change during query execution.
> If you're desperate you can construct a query string
On Tue, Jun 13, 2006 at 09:50:49PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Tue, Jun 13, 2006 at 06:04:42PM -0400, Tom Lane wrote:
> >> It'd depend on the context, possibly, but it's easy to show that the
> >> current planner does fold "now() - interval_constant" w
"Shaun Thomas" <[EMAIL PROTECTED]> writes:
> I can see the planner not liking the results of a function,
> but a variable? That's a static value!
Read what you wrote, and rethink...
If you're desperate you can construct a query string with the variable
value embedded as a literal, and then EXECU
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Jun 13, 2006 at 06:04:42PM -0400, Tom Lane wrote:
>> It'd depend on the context, possibly, but it's easy to show that the
>> current planner does fold "now() - interval_constant" when making
>> estimates. Simple example:
> Turns out the differe
On Tue, Jun 13, 2006 at 05:41:06PM -0500, Shaun Thomas wrote:
> >>> On 6/13/2006 at 4:54 PM, "Jim C. Nasby" <[EMAIL PROTECTED]>
> wrote:
>
> > SELECT attname, attstattarget
> > FROM pg_attribute
> > WHERE attrelid='table_name'::regclass AND attnum >= 0;
>
> -1 for all values.
>
> > SHOW
>>> On 6/13/2006 at 4:54 PM, "Jim C. Nasby" <[EMAIL PROTECTED]>
wrote:
> SELECT attname, attstattarget
> FROM pg_attribute
> WHERE attrelid='table_name'::regclass AND attnum >= 0;
-1 for all values.
> SHOW default_statistics_target;
10.
Here's something slightly annoying: I tried preca
On Tue, Jun 13, 2006 at 06:04:42PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Also, I'm not sure that the behavior is entirely changed, either. On a
> > 8.1.4 database I'm still seeing a difference between now() - interval
> > and a hard-coded date.
>
> It'd depend on
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Also, I'm not sure that the behavior is entirely changed, either. On a
> 8.1.4 database I'm still seeing a difference between now() - interval
> and a hard-coded date.
It'd depend on the context, possibly, but it's easy to show that the
current planner
On Tue, Jun 13, 2006 at 04:35:41PM -0500, Shaun Thomas wrote:
> >>> On 6/13/2006 at 4:13 PM, "Jim C. Nasby" <[EMAIL PROTECTED]>
> wrote:
>
>
> > Is there some compelling reason to stick with 7.4? In my experience
> > you'll see around double (+100%) the performance going to 8.1...
>
> Not really
>>> On 6/13/2006 at 4:13 PM, "Jim C. Nasby" <[EMAIL PROTECTED]>
wrote:
> Is there some compelling reason to stick with 7.4? In my experience
> you'll see around double (+100%) the performance going to 8.1...
Not really. We *really* want to upgrade, but we're in the middle of
buying the new mach
On Tue, Jun 13, 2006 at 03:54:44PM -0500, Shaun Thomas wrote:
> >>> On 6/13/2006 at 1:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > I missed the part where you explain why you think this plan is
> terrible?
> > 412ms for what seems a rather expensive query doesn't sound so
> awful.
>
> Sorry,
"Shaun Thomas" <[EMAIL PROTECTED]> writes:
> Simply changing:
> now() - interval '2 days'
> to
> '2006-06-11 15:30:00'
> generated a much more accurate set of estimates.
Yeah, 7.4 won't risk basing estimates on the results of non-immutable
functions. We relaxed that in 8.0 I believe.
>>> On 6/13/2006 at 1:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I missed the part where you explain why you think this plan is
terrible?
> 412ms for what seems a rather expensive query doesn't sound so
awful.
Sorry, I based that statement on the estimated/actual disparity. That
particular que
> warehouse-# WHERE e.event_date > now() - interval '2 days'
Try explicitly querying:
WHERE e.event_date > '2006-06-11 20:15:00'
In my understanding 7.4 does not precalculate this timestamp value for the
purpose of choosing a plan.
Greetings
Marcin
---(end of broadc
"Shaun Thomas" <[EMAIL PROTECTED]> writes:
> Am I correct in assuming this terrible plan is due to our ancient
> version of Postgres?
I missed the part where you explain why you think this plan is terrible?
412ms for what seems a rather expensive query doesn't sound so awful.
Do you know an altern
Just so I don't think I'm insane:
warehouse=# explain analyzeselect e.event_date::date
warehouse-# from l_event_log e
warehouse-# JOIN c_event_type t ON (t.id = e.event_type_id)
warehouse-# WHERE e.event_date > now() - interval '2 days'
warehouse-# AND t.event_name = 'activ
19 matches
Mail list logo
