Shaun Thomas writes:
> On 06/27/2013 01:42 PM, Tom Lane wrote:
>> That will break things: CURRENT_DATE will then be equivalent to just
>> writing today's date as a literal.
> Interesting. I tested it by creating a view and a table with a default,
> and it always seems to get translated to:
> ('n
Andres Freund writes:
> Couldn't we at least significantly improve on the status quo by
> detecting we're currently planning a query that's only going to be
> executed once (because it's directly executed or because were planning a
> onetime plan for specific parameters) and inline stable function
> At this point I wonder why CURRENT_DATE even exists, if using it is
> apparently detrimental to query execution.
It's good for inserts. ;-)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make ch
On 2013-06-27 14:42:26 -0400, Tom Lane wrote:
> Shaun Thomas writes:
> > On 06/27/2013 12:42 PM, Dave Johansen wrote:
> >> Or what about something like DATE_TRUNC("DAY", now())? Or would that run
> >> into the same optimization/planner problems as CURRENT_DATE?
>
> > Same issue. This seems to wor
On 06/27/2013 02:49 PM, Andrew Dunstan wrote:
But that's a lie, surely. If it breaks you have nobody to blame but
yourself. There's a reason EDB haven't marked their function
immutable - it's not.
Well, yeah. That's why I'm testing it in a dev system. :)
None of this will probably pan out, bu
On 06/27/2013 03:14 PM, Shaun Thomas wrote:
On 06/27/2013 01:42 PM, Tom Lane wrote:
That will break things: CURRENT_DATE will then be equivalent to just
writing today's date as a literal.
Interesting. I tested it by creating a view and a table with a
default, and it always seems to get tran
On 06/27/2013 01:45 PM, Albin, Lloyd P wrote:
We have also run into this with our production databases. We worked
around the issue by adding an index to each child table so that it
scans all the child index's instead of the child table's. For us
this made a large performance improvement.
Haha.
On 06/27/2013 01:42 PM, Tom Lane wrote:
That will break things: CURRENT_DATE will then be equivalent to just
writing today's date as a literal.
Interesting. I tested it by creating a view and a table with a default,
and it always seems to get translated to:
('now'::text)::date
But I'll tak
We have also run into this with our production databases. We worked around the
issue by adding an index to each child table so that it scans all the child
index's instead of the child table's. For us this made a large performance
improvement.
CREATE INDEX part_test_1_idx ON part_test_1
USING
Shaun Thomas writes:
> On 06/27/2013 12:42 PM, Dave Johansen wrote:
>> Or what about something like DATE_TRUNC("DAY", now())? Or would that run
>> into the same optimization/planner problems as CURRENT_DATE?
> Same issue. This seems to work, though I'm not entirely sure of the
> implications:
>
On 06/27/2013 12:42 PM, Dave Johansen wrote:
Or what about something like DATE_TRUNC("DAY", now())? Or would that run
into the same optimization/planner problems as CURRENT_DATE?
Same issue. This seems to work, though I'm not entirely sure of the
implications:
UPDATE pg_proc
SET provolat
On Thu, Jun 27, 2013 at 10:34 AM, bricklen wrote:
> On Thu, Jun 27, 2013 at 10:17 AM, Shaun Thomas
> wrote:
>
>>
>> Well yeah. That's not really the point, though. Aside from existing code,
>> hard-coding is generally frowned upon. Our devs have been using
>> CURRENT_DATE and its ilk for over si
On Thu, Jun 27, 2013 at 10:17 AM, Shaun Thomas wrote:
>
> Well yeah. That's not really the point, though. Aside from existing code,
> hard-coding is generally frowned upon. Our devs have been using
> CURRENT_DATE and its ilk for over six years now.
>
Would it help to put the current_date call in
On 06/27/2013 12:08 PM, Igor Neyman wrote:
Doesn't have to be hardcoded.
If executed as dynamic sql, it will be re-planned properly, e.g.:
Well yeah. That's not really the point, though. Aside from existing
code, hard-coding is generally frowned upon. Our devs have been using
CURRENT_DATE an
> -Original Message-
> From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-
> performance-ow...@postgresql.org] On Behalf Of Shaun Thomas
> Sent: Thursday, June 27, 2013 12:16 PM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] Partitions not Working as Expected
>
> Hey g
Hey guys,
I suspect I'll get an answer equivalent to "the planner treats that like
a variable," but I really hope not because it renders partitions
essentially useless to us. This is as recent as 9.1.9 and constraint
exclusion is enabled.
What I have is this test case:
CREATE TABLE part_tes
16 matches
Mail list logo
