Hi,
I have tried unix domain socket and the performance is similar with TCP
socket. It is MIPS architecture so memory copy to/from kernel can occupy
much time, and apparently using unit domain socket has no difference than
TCP in terms of memory copy.
But it is still unbelievable for the ten-fold
On Fri, Feb 10, 2012 at 10:30 AM, Peter Geoghegan wrote:
> [ new patch ]
I spent quite a bit of time looking at this today - the patch
specifically, and the issue of making quicksort fast more generally.
It seemed to me that if we're going to have separate copies of the
quicksort code for tuple s
On 02/14/2012 05:39 PM, Tom Lane wrote:
OK, I fixed this up and committed it. I made some cosmetic changes
(the most notable being that the definition of RowExpr is really
changing here, and so should its comment). The adjust_appendrel_attrs
situation was fixed by passing in the PlannerInfo,
Hi,
I am checking a performance problem encountered after porting old embeded
DB to postgreSQL. While the system is real-time sensitive, we are
concerning for per-query cost. In our environment sequential scanning
(select * from ...) for a table with tens of thousands of record costs 1 -
2 seconds
On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
> On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
> > >> +1, I was about to suggest the same thing. Running any of these tests
> > >> fo
On 13/02/2012 08:26, Greg Smith wrote:
On 02/11/2012 08:14 PM, Gaetano Mendola wrote:
The trend is to have server capable of running CUDA providing GPU via
external hardware (PCI Express interface with PCI Express switches),
look for example at PowerEdge C410x PCIe Expansion Chassis from DELL.
On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
> > On 14.02.2012 04:57, Dan Ports wrote:
> >> The easiest answer would be to just treat every prepared
> >> transaction found during recovery as though it had a conflict in
> >> and out. This is roughly a
On Tue, Feb 14, 2012 at 10:04:15AM +0200, Heikki Linnakangas wrote:
> Perhaps it would be simpler to add the extra information to the commit
> records of the transactions that commit after the first transaction is
> prepared. In the commit record, you would include a list of prepared
> transacti
On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
> >> +1, I was about to suggest the same thing. Running any of these tests
> >> for a fixed number of iterations will result in drastic degradation of
>
Bruce Momjian writes:
> On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
>> +1, I was about to suggest the same thing. Running any of these tests
>> for a fixed number of iterations will result in drastic degradation of
>> accuracy as soon as the machine's behavior changes noticeably fro
Alexander Korotkov writes:
> ITSM, I found the problem. This piece of code is triggering an error. It
> assumes each page of corresponding to have initialized buffer. That should
> be true because we're inserting index tuples from up to down while
> splits propagate from down to up.
> But this ass
Andrew Dunstan writes:
> On 02/13/2012 11:00 AM, Tom Lane wrote:
>> This is surely fixable by passing a bit more information down. If you
>> (Andrew) have something that covers everything but this issue, pass it
>> over and I'll take a whack at it.
> What I have fixes one of the three cases I ha
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That should
be true because we're inserting index tuples from up to down while
splits propagate from down to up.
if (!found)
{
/*
* Node buffer should exist at t
On Tue, Feb 07, 2012 at 07:58:28PM -0500, Bruce Momjian wrote:
> I was initially concerned that tuning advice in this part of the docs
> would look out of place, but now see the 25% shared_buffers
> recommentation, and it looks fine, so we are OK. (Should we caution
> against more than 8GB of shar
On 02/14/2012 01:45 PM, Greg Smith wrote:
scale=1000, db is 94% of RAM; clients=4
Version TPS
9.0 535
9.1 491 (-8.4% relative to 9.0)
9.2 338 (-31.2% relative to 9.1)
A second pass through this data noted that the maximum number of buffers
cleaned by the background writer is <=2785 in 9.0/9
Last year at this time, I was investigating things like ext3 vs xfs, how
well Linux's dirty_bytes parameter worked, and how effective a couple of
patches were on throughput & latency. The only patch that ended up
applied for 9.1 was for fsync compaction. That was measurably better in
terms of
On Mon, Feb 13, 2012 at 09:54:06PM -0500, Bruce Momjian wrote:
> On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > Instead of or in addition to a fixed number operations per test, maybe
> > > we should cut off each test after a certain amount of wall-clock tim
"Kevin Grittner" wrote:
> This would tend to be more than a little inconvenient until the
> prepared statements pending at crash or shutdown were all
> committed or rolled back.
[sigh]
Probably obvious, but to avoid confusion:
s/prepared statements/prepared transactions/
-Kevin
--
Sent
Heikki Linnakangas wrote:
> On 14.02.2012 04:57, Dan Ports wrote:
>> Looking over the SSI 2PC code recently, I noticed that I
>> overlooked a case that could lead to non-serializable behavior
>> after a crash.
>>
>> When we PREPARE a serializable transaction, we store part of the
>> SERIALIZABLEXA
Shigeru Hanada writes:
> (2012/02/14 17:40), Etsuro Fujita wrote:
>> As discussed at
>> that thread, it would have to change the PlanForeignScan API to let the
>> FDW generate multiple paths and dump them all to add_path instead of
>> returning a FdwPlan struct.
> Multiple valuable Paths for a sc
2012/2/14 Robert Haas :
> On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai wrote:
>> I could not find out where is the origin of grammer conflicts, although
>> it does not conflict with any options within ALTER FUNCTION.
>>
>> Do you think the idea of ALTER ... NOT LEAKPROOF should be
>> integrated w
On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai wrote:
> I could not find out where is the origin of grammer conflicts, although
> it does not conflict with any options within ALTER FUNCTION.
>
> Do you think the idea of ALTER ... NOT LEAKPROOF should be
> integrated within v9.2 timeline also?
Yes.
Excerpts from Jaime Casanova's message of mar feb 14 04:10:58 -0300 2012:
> On Thu, Feb 2, 2012 at 2:32 AM, Magnus Hagander wrote:
> >
> > I haven't looked through the code in detail, but one direct comment:
> > do we really need/want to send this through the stats collector? It
> > will only eve
(2012/02/14 19:42), Shigeru Hanada wrote:
> (2012/02/14 17:40), Etsuro Fujita wrote:
>> As discussed at
>> that thread, it would have to change the PlanForeignScan API to let the
>> FDW generate multiple paths and dump them all to add_path i
(2012/02/14 17:40), Etsuro Fujita wrote:
> OK. But my question was about the PlanForeignScan API.
Sorry for misunderstanding. :(
> As discussed at
> that thread, it would have to change the PlanForeignScan API to let the
> FDW generate mul
2012/2/14 Robert Haas :
> On Mon, Feb 13, 2012 at 7:51 AM, Kohei KaiGai wrote:
>> I rebased the patch due to the updates of pg_proc.h.
>>
>> Please see the newer one. Thanks,
>
> Thanks, committed. I think, though, that some further adjustment is
> needed here, because you currently can't do ALTE
On Sat, Feb 11, 2012 at 11:34 AM, Jeff Janes wrote:
> On Wed, Feb 8, 2012 at 1:01 AM, Hitoshi Harada wrote:
>> On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes wrote:
>>>
>>> The attached patch allows it to reuse that memory. On my meager
>>> system it reduced the building of an index on an integer
(2012/02/14 15:15), Shigeru Hanada wrote:
> (2012/02/13 20:50), Etsuro Fujita wrote:
>> The patches have been applied, but role-related regression tests failed
>> in my environment. I fixed it in a similar fashion of
>> /src/test/regress/sql/foreign_data.sql. Please find attached a updated
>> pat
On 14.02.2012 04:57, Dan Ports wrote:
Looking over the SSI 2PC code recently, I noticed that I overlooked a
case that could lead to non-serializable behavior after a crash.
When we PREPARE a serializable transaction, we store part of the
SERIALIZABLEXACT in the statefile (in addition to the list
29 matches
Mail list logo
