On Jun 16, 2011, at 1:36 PM, Shaun Thomas wrote:
> /**
> * Return the Maximum INT Value for a Partitioned Table Column
> *
> * @param string Name of Schema of the base partition table.
> * @param string Name of the base partition table.
> * @param string Name of column to search.
> */
> CREATE O
On 06/17/2011 08:43 AM, Shaun Thomas wrote:
It's a bit of a hack, but it's worked fine for us while we wait for
the planner to catch up. :)
Right. In situations where people can modify their application to
redirect MIN/MAX() calls over to directly query the individual
partitions, that's a gr
On 06/17/2011 08:48 AM, Kabu Taah wrote:
Load testing of postgresql 8.4 for OLTP application suitability showed
that throughput of the database significantly degraded over time from
thousands of write transactions per second to almost zero...Postgres
performance degraded in a couple of minute
On Fri, Jun 17, 2011 at 7:48 AM, Kabu Taah wrote:
> Load testing of postgresql 8.4 for OLTP application suitability showed that
> throughput of the database significantly degraded over time from thousands
> of write transactions per second to almost zero. Write transactions are in
> given case ins
Yes, confirmed that the problem is in the partitioned table.
Shaun, that solution is brilliant.
Thank you,
Svetlin Manavski
On Thu, Jun 16, 2011 at 7:36 PM, Shaun Thomas wrote:
> On 06/16/2011 12:25 PM, Magnus Hagander wrote:
>
> PostgreSQL 9.0 is unable to use an index scan to find min/max on
Load testing of postgresql 8.4 for OLTP application
suitability showed that throughput of the
database significantly degraded over time from thousands of write
transactions per second to almost zero. Write transactions are in given
case insert/update/delete database transaction
On Thu, Jun 16, 2011 at 5:44 PM, Merlin Moncure wrote:
> it's complex -- but I think the whole issue becomes moot soon because
> non consumer flash drives from here on out are going to have
> capacitors in them (the 720 ramsdale will immediately knock out the
> x25-e). So the prudent course of act
On 06/17/2011 06:22 AM, Svetlin Manavski wrote:
Shaun, that solution is brilliant.
Don't thank me. I actually got the basic idea from a post here a couple
years ago. The only difference is I formalized it somewhat and put it in
our utility schema, where I put lots of other random useful stor
> On Jun 16, 2011, at 20:43, Greg Smith wrote:
>> The layout you proposed (OS+WAL , data) might be effective, but if your
>> write volume is low it may not be much of an improvement at all over a
>> simple RAID1 of two drives. The odds that you are going to correctly
>> lay out individual section
On Jun 16, 2011, at 20:43, Greg Smith wrote:
> The layout you proposed (OS+WAL , data) might be effective, but if your write
> volume is low it may not be much of an improvement at all over a simple RAID1
> of two drives. The odds that you are going to correctly lay out individual
> sections o
On Jun 16, 2011, at 20:29, Jesper Krogh wrote:
> On 2011-06-16 17:09, Haestan wrote:
>> I am evaluating hardware for a new PostgreSQL server. For reasons
>> concerning power consumption and available space it should not have
>> more than 4 disks (in a 1U case), if possible. Now, I am not sure wha
11 matches
Mail list logo
