Greg Smith wrote:
> On Wed, 1 Apr 2009, Scott Carey wrote:
>
>> Write caching on SATA is totally fine. There were some old ATA drives
>> that when paried with some file systems or OS's would not be safe. There are
>> some combinations that have unsafe write barriers. But there is a
>> standard
Tom Lane wrote:
> Gregory Stark writes:
> > Tom Lane writes:
> >> Ugh. So apparently, we actually need to special-case Solaris to not
> >> believe that posix_fadvise works, or we'll waste cycles uselessly
> >> calling a do-nothing function. Thanks, Sun.
>
> > Do we? Or do we just document that
On 4/2/09 1:20 PM, "Scott Carey" wrote:
>
> Well, raid block size can be significantly larger than postgres or file
> system block size and the performance of random reads / writes won't get
> worse with larger block sizes. This holds only for RAID 0 (or 10), parity
> is the ONLY thing that mak
On 4/2/09 1:53 AM, "Greg Smith" wrote:
> On Wed, 1 Apr 2009, Scott Carey wrote:
>
>> Write caching on SATA is totally fine. There were some old ATA drives that
>> when paried with some file systems or OS's would not be safe. There are
>> some combinations that have unsafe write barriers. But
On Thu, Apr 2, 2009 at 4:20 PM, Scott Carey wrote:
>
> On 4/2/09 10:58 AM, "Merlin Moncure" wrote:
>
>> On Wed, Mar 25, 2009 at 12:16 PM, Scott Carey
>> wrote:
>>> On 3/25/09 1:07 AM, "Greg Smith" wrote:
On Wed, 25 Mar 2009, Mark Kirkwood wrote:
> I'm thinking that the raid chunksize
On 4/2/09 10:58 AM, "Merlin Moncure" wrote:
> On Wed, Mar 25, 2009 at 12:16 PM, Scott Carey wrote:
>> On 3/25/09 1:07 AM, "Greg Smith" wrote:
>>> On Wed, 25 Mar 2009, Mark Kirkwood wrote:
I'm thinking that the raid chunksize may well be the issue.
>>>
>>> Why? I'm not saying you're wron
>> I still have some work to do to find out why dumping in the custom
>> format is so much slower.
>
> Offhand the only reason I can see for it to be much different from
> plain-text output is that -Fc compresses by default. If you don't
> care about that, try -Fc -Z0.
Ok, I did some performanc
Greg Smith wrote:
OK, that's clearly cached writes where the drive is lying about fsync.
The claim is that since my drive supports both the flush calls, I just
need to turn on barrier support, right?
That's a big pointy finger you are aiming at that drive - are you sure
it was sent the flush
On Wed, Mar 25, 2009 at 12:16 PM, Scott Carey wrote:
> On 3/25/09 1:07 AM, "Greg Smith" wrote:
>> On Wed, 25 Mar 2009, Mark Kirkwood wrote:
>>> I'm thinking that the raid chunksize may well be the issue.
>>
>> Why? I'm not saying you're wrong, I just don't see why that parameter
>> jumped out as
Matthew Wakeling wrote:
> Trying to rewrite a plpgsql function in C.
>
> How do I do the equivalent of:
>
> FOR loc IN SELECT * FROM location ORDER BY objectid, intermine_start,
> intermine_end LOOP
> END LOOP;
>
> in a C function?
Please create a new message to the list with a new subject line
Trying to rewrite a plpgsql function in C.
How do I do the equivalent of:
FOR loc IN SELECT * FROM location ORDER BY objectid, intermine_start,
intermine_end LOOP
END LOOP;
in a C function?
Matthew
--
I wouldn't be so paranoid if you weren't all out to get me!!
--
Sent via pgsql-performance
On Wed, 1 Apr 2009, Scott Carey wrote:
Write caching on SATA is totally fine. There were some old ATA drives that
when paried with some file systems or OS's would not be safe. There are
some combinations that have unsafe write barriers. But there is a standard
well supported ATA command to sy
12 matches
Mail list logo
