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_test
-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 guys
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
On Thu, Jun 27, 2013 at 10:17 AM, Shaun Thomas stho...@optionshouse.comwrote:
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
On Thu, Jun 27, 2013 at 10:34 AM, bricklen brick...@gmail.com wrote:
On Thu, Jun 27, 2013 at 10:17 AM, Shaun Thomas
stho...@optionshouse.comwrote:
Well yeah. That's not really the point, though. Aside from existing code,
hard-coding is generally frowned upon. Our devs have been using
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
Shaun Thomas stho...@optionshouse.com 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
: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Shaun Thomas
Sent: Thursday, June 27, 2013 11:16 AM
To: Dave Johansen
Cc: bricklen; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Partitions not Working as Expected
On 06/27/2013 12:42 PM
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
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.
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
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,
On 2013-06-27 14:42:26 -0400, Tom Lane wrote:
Shaun Thomas stho...@optionshouse.com 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
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
Andres Freund and...@2ndquadrant.com 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
Shaun Thomas stho...@optionshouse.com 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
16 matches
Mail list logo
