If you are using ext3, your performance on the RAID card may also improve if
the postgres xlog is not on the same partition as the data. Otherwise, for
every transaction commit, all of the data on the whole partition will have to
be sync()'d not just the xlog.
Also, what is the performance dif
Hello
2010/7/20 Kneringer, Armin :
> Hi there.
>
> I think I found a potential performance gain if the query planner would be
> optimized. All Tests has been performed with 8.4.1 (and earlier versions) on
> CentOS 5.3 (x64)
>
> The following query will run on my database (~250 GB) for ca. 1600 s
Hi there.
I think I found a potential performance gain if the query planner would be
optimized. All Tests has been performed with 8.4.1 (and earlier versions) on
CentOS 5.3 (x64)
The following query will run on my database (~250 GB) for ca. 1600 seconds and
the sort will result in a disk merge
Tuesday, July 20, 2010, 5:36:07 PM you wrote:
> 2) the above query creates a plan that does a sequential scan & filter on
> every partition. Why won't it only hit the correct partitions? Is it due to
> the way the date was specified? or maybe the "at time zone" syntax?
Quick guess: How is your
On Tue, 2010-07-20 at 09:36 -0600, Kevin Kempter wrote:
> Hi All;
>
> we have a table partitioned by day, the check constraint on the child tables
> looks like this (this is the may 31st partition):
>
> CHECK
> (stime >= '2010-05-30 00:00:00+00'::timestamp with time zone
> AND stime <= '2010
Hi All;
we have a table partitioned by day, the check constraint on the child tables
looks like this (this is the may 31st partition):
CHECK
(stime >= '2010-05-30 00:00:00+00'::timestamp with time zone
AND stime <= '2010-05-30 23:59:59+00'::timestamp with time zone)
We have a python based
