On Mon, Jan 30, 2012 at 1:39 AM, Jeff Davis wrote:
> Thank you for the updates. I have a small patch attached.
>
> The only code change I made was very minor: I changed the constants used
> in the penalty function because your version used INFINITE_BOUND_PENALTY
> when adding an empty range, and
Excerpts from Tom Lane's message of dom ene 29 22:13:43 -0300 2012:
>
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of sáb ene 28 01:35:33 -0300 2012:
> >> This is the same thing I was complaining about in the bug #6123 thread,
> >> http://archives.postgresql.org/message-id/9698.
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of sáb ene 28 01:35:33 -0300 2012:
>> This is the same thing I was complaining about in the bug #6123 thread,
>> http://archives.postgresql.org/message-id/9698.1327266...@sss.pgh.pa.us
> Hm. Okay, I hadn't read that.
> In my FOR KEY SHAR
Excerpts from Tom Lane's message of sáb ene 28 01:35:33 -0300 2012:
> Alvaro Herrera writes:
> > I expected the FETCH to return one row, with the latest data, i.e.
> > (1, 3), but instead it's returning empty.
>
> This is the same thing I was complaining about in the bug #6123 thread,
> http://a
On Sun, Jan 15, 2012 at 12:24 AM, Greg Smith wrote:
> If you then turn that equation around, making the maximum write rate the
> input, for any given cost delay and dirty page cost you can solve for the
> cost limit--the parameter in fictitious units everyone hates. It works like
> this, with th
On Sun, Jan 29, 2012 at 9:41 PM, Jeff Janes wrote:
> If I cast to a int, then I see advancement:
I'll initialise it as 0, rather than -1 and then we don't have a
problem in any circumstance.
>> I've specifically designed the pgbench changes required to simulate
>> conditions of clog contention
On Sun, Jan 29, 2012 at 1:41 PM, Jeff Janes wrote:
> On Sun, Jan 29, 2012 at 12:18 PM, Simon Riggs wrote:
>> On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
>>> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
Yes, it was. Sorry about that. New version attached, retesting while
On Thu, Jan 26, 2012 at 2:25 AM, Robert Haas wrote:
> On Sat, Jan 21, 2012 at 10:11 AM, Simon Riggs wrote:
>> Your caution is wise. All users of an index have already checked
>> whether the index is usable at plan time, so although there is much
>> code that assumes they can look at the index its
On Sun, Jan 29, 2012 at 12:18 PM, Simon Riggs wrote:
> On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
>> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>>>
>>> Yes, it was. Sorry about that. New version attached, retesting while
>>> you read this.
>>
>> In my hands I could never get th
On Tue, 2012-01-24 at 16:07 +0400, Alexander Korotkov wrote:
> Hi!
>
>
> New version of patch is attached.
Thank you for the updates. I have a small patch attached.
The only code change I made was very minor: I changed the constants used
in the penalty function because your version used INFINIT
On 01/28/2012 07:48 PM, Jeff Janes wrote:
Others are going to test this out on high-end systems. I wanted to
try it out on the other end of the scale. I've used a Pentium 4,
3.2GHz,
with 2GB of RAM and with a single IDE drive running ext4. ext4 is
amazingly bad on IDE, giving about 25 fsync's p
On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>>
>> Yes, it was. Sorry about that. New version attached, retesting while
>> you read this.
>
> In my hands I could never get this patch to do anything. The new
> cache was never used.
>
>
We apologize that http://www.bsdcan.org/ was offline for 12 hours from early
Sunday morning.
The deadline for submissions has been extended to Tuesday 31 January.
PGCon 2012 will be held 17-18 May 2012, in Ottawa at the University of
Ottawa. It will be preceded by two days of tutorials on 15-16
On 2012-01-29 01:48, Jeff Janes wrote:
I ran three modes, head, head with commit_delay, and the group_commit patch
shared_buffers = 600MB
wal_sync_method=fsync
optionally with:
commit_delay=5
commit_siblings=1
pgbench -i -s40
for clients in 1 5 10 15 20 25 30
pgbench -T 30 -M prepared -c $cli
Hi Harada-san,
I checked the "fdw_helper_funcs_v3.patch", "pgsql_fdw_v5.patch" and
"pgsql_fdw_pushdown_v1.patch". My comments are below.
[BUG]
Even though pgsql_fdw tries to push-down qualifiers being executable
on the remove side at the deparseSql(), it does not remove qualifiers
being pushed do
On Sat, Jan 28, 2012 at 1:52 PM, Simon Riggs wrote:
>> Also, I think the general approach is wrong. The only reason to have
>> these pages in shared memory is that we can control access to them to
>> prevent write/write and read/write corruption. Since these pages are
>> never written, they don
Joachim Wieland writes:
> I know that you took back some of your comments, but I'm with you
> here. Archive is allocated as an ArchiveHandle and then casted back to
> Archive*, so you always know that an Archive is an ArchiveHandle. I'm
> all for getting rid of Archive and just using ArchiveHandle
On Fri, Jan 27, 2012 at 4:57 PM, Robert Haas wrote:
> But even if you do know that subclassing
> is intended, that doesn't prove that the particular Archive object is
> always going to be an ArchiveHandle under the hood. If it is, why not
> just pass it as an ArchiveHandle to begin with?
I know
2012/1/28 Kohei KaiGai :
> 2012/1/26 Robert Haas :
>> On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai wrote:
>>> 2012/1/26 Robert Haas :
I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC change -
i.e. if so
On 25/01/12 18:37, Hitoshi Harada wrote:
>> I'm still not sure whether to just revise (almost) all the SQL function
>> examples to use parameter names, and declare them the "right" choice; as
>> it's currently written, named parameters still seem rather second-class.
>
> Agreed.
I'll try a more
20 matches
Mail list logo
