On 07/14/2011 04:03 PM, Jeff Janes wrote:
On Wed, Jul 13, 2011 at 3:41 PM, lars wrote:
On 07/13/2011 11:42 AM, Kevin Grittner wrote:
So transactions without an XID *are* sensitive to
synchronous_commit. That's likely a useful clue.
How much did it help the run time of the SELECT which follow
On 07/10/2011 02:31 PM, Samuel Gendler wrote:
What about partitioning tables by tenant id and then maintaining
indexes on each partition independent of tenant id, since constraint
exclusion should handle filtering by tenant id for you. That seems
like a potentially more tolerable variant of #5
On 7/14/11 11:34 PM, chris wrote:
> Any comments on the configuration? Any experiences with iSCSI vs. Fibre
> Channel for SANs and PostgreSQL? If the SAN setup sucks, do you see a
> cheap alternative how to connect as many as 16 x 2TB disks as DAS?
Here's the problem with iSCSI: on gigabit etherne
On Fri, Jul 15, 2011 at 11:49 AM, chris r. wrote:
> Hi list,
>
> Thanks a lot for your very helpful feedback!
>
>> I've tested MD1000, MD1200, and MD1220 arrays before, and always gotten
>> seriously good performance relative to the dollars spent
> Great hint, but I'm afraid that's too expensive f
Hi list,
Thanks a lot for your very helpful feedback!
> I've tested MD1000, MD1200, and MD1220 arrays before, and always gotten
> seriously good performance relative to the dollars spent
Great hint, but I'm afraid that's too expensive for us. But it's a great
way to scale over the years, I'll kee
> Just to add to the conversation, there's no real advantage to putting
> WAL on SSD. Indexes can benefit from them, but WAL is mosty
> seqwuential throughput and for that a pair of SATA 1TB drives at
> 7200RPM work just fine for most folks.
Actually, there's a strong disadvantage to putting W
On Fri, Jul 15, 2011 at 10:39 AM, Robert Schnabel
wrote:
> I'm curious what people think of these:
> http://www.pc-pitstop.com/sas_cables_enclosures/scsase166g.asp
>
> I currently have my database on two of these and for my purpose they seem to
> be fine and are quite a bit less expensive than the
On Fri, Jul 15, 2011 at 12:34 AM, chris wrote:
> I was thinking to put the WAL and the indexes on the local disks, and
> the rest on the SAN. If funds allow, we might downgrade the disks to
> SATA and add a 50 GB SATA SSD for the WAL (SAS/SATA mixup not possible).
Just to add to the conversation,
Svetlin Manavski writes:
> The question is: why do we get a seq scan on appqosdata.tcpsessiondata_1 and
> appqosdata.tcpsessiondata_2 even if the planner estimates correctly 1 row
> out of millions could potentially be selected? As you can see ~90% of the
> time is spent on those 2 partitions even
On 7/15/2011 2:10 AM, Greg Smith wrote:
chris wrote:
My employer is a university with little funds and we have to find a
cheap way to scale for the next 3 years, so the SAN seems a good chance
to us.
A SAN is rarely ever the cheapest way to scale anything; you're paying
extra for reliability i
Hi all,
here is my postgresql configuration:
"version";"PostgreSQL 9.0.3 on amd64-portbld-freebsd8.0, compiled by GCC cc
(GCC) 4.2.1 20070719 [FreeBSD], 64-bit"
"bytea_output";"escape"
"checkpoint_segments";"64"
"client_encoding";"UNICODE"
"effective_cache_size";"6GB"
"fsync";"off"
"lc_collate";"
> 1 x Intel Xeon X5670, 6C, 2.93GHz, 12M Cache
> 16 GB (4x4GB) Low Volt DDR3 1066Mhz
> PERC H700 SAS RAID controller
> 4 x 300 GB 10k SAS 6Gbps 2.5" in RAID 10
Apart from Gregs excellent recommendations. I would strongly suggest
more memory. 16GB in 2011 is really on the low side.
PG is u
On 20/06/2011 07:35, Vladimir Kulev wrote:
But this does not work:
# explain analyze select max(timestamp) from sms where number in
('5502712','5802693','5801981');
Try to rewrite that query this way:
explain analyze select timestamp from sms where number in
('5502712','5802693','5801981') o
On 20/06/2011 07:35, Vladimir Kulev wrote:
But this does not work:
# explain analyze select max(timestamp) from sms where number in
('5502712','5802693','5801981');
Try to rewrite that query this way:
explain analyze select timestamp from sms where number in
('5502712','5802693','5801981') o
chris wrote:
My employer is a university with little funds and we have to find a
cheap way to scale for the next 3 years, so the SAN seems a good chance
to us.
A SAN is rarely ever the cheapest way to scale anything; you're paying
extra for reliability instead.
I was thinking to put the WA
15 matches
Mail list logo
