I had the possibility to perform tests on 9.5, and can confirm the
memory leak I was seeing is solved with the patch (and that's great :) )
Regards
Marc
On 18/04/2016 17:53, Julien Rouhaud wrote:
> On 18/04/2016 16:33, Tom Lane wrote:
>> I poked at this over the weekend, and got more unhappy t
On 27/02/2015 20:01, Marc Cousin wrote:
> On 27/02/2015 19:45, Tom Lane wrote:
>>> I wrote:
>>>> I had actually thought that we'd fixed this type of problem in recent
>>>> versions, and that you should be able to get a plan that would look
>&g
On 27/02/2015 19:45, Tom Lane wrote:
I wrote:
I had actually thought that we'd fixed this type of problem in recent
versions, and that you should be able to get a plan that would look like
Nestloop
-> scan dim1
-> Nestloop
-> scan dim2
-> indexscan fact table using dim1.
On 27/02/2015 15:27, Marc Cousin wrote:
> On 27/02/2015 15:08, Tom Lane wrote:
>> Marc Cousin writes:
>>> So I gave a look at the optimizer's code to try to understand why I got
>>> this problem. If I understand correctly, the optimizer won't do cross
On 27/02/2015 15:08, Tom Lane wrote:
> Marc Cousin writes:
>> So I gave a look at the optimizer's code to try to understand why I got this
>> problem. If I understand correctly, the optimizer won't do cross joins,
>> except if it has no choice.
>
> That&
Hi all,
I've been facing an issue with star schemas for a while. PostgreSQL's
performance is not that good without rewriting the query (or at least I
couldn't find a way to make it do what I want).
Here is a very basic mockup schema I used for the rest of this mail. It's of
course too small to
On Tuesday 08 October 2013 12:28:46 Robert Haas wrote:
> On Mon, Oct 7, 2013 at 12:32 PM, Marc Cousin wrote:
> > I was using the lo contrib a few days ago and wasn't paying attention, and
> > forgot the "for each row" in the create trigger command... PostgreSQL
&g
I was using the lo contrib a few days ago and wasn't paying attention, and
forgot the "for each row" in the create trigger command... PostgreSQL
segfaulted, when the trigger tried to access the row's attributes.
Please find attached a patch to control that the trigger is correctly defined
(as i
On 24/08/2013 21:16, Tom Lane wrote:
Marc Cousin writes:
On 23/08/2013 23:55, Tom Lane wrote:
My previous suggestion was to estimate planning cost as
10 * (length(plan->rangetable) + 1)
but on reflection it ought to be scaled by one of the cpu cost constants,
so perhaps
1
On 23/08/2013 23:55, Tom Lane wrote:
Pavel Stehule writes:
please, can you send a self explained test
this issue should be fixed, and we need a examples.
We already had a perfectly good example at the beginning of this thread.
What's missing is a decision on how we ought to approximate the cos
Hi,
I've been trying to diagnose a severe performance regression we've been
having in one of our plpgsql procedures.
The example below is of course extremely simplified, and obviously not
what we are really doing in the database, but it exhibits the slowdown
between 9.1.9 and 9.2.4.
So here is t
On 20/03/2013 16:33, Alvaro Herrera wrote:
Marc Cousin escribió:
Hi,
I'm trying to write a background writer, and I'm facing a problem with
timestamps. The following code is where I'm having a problem (it's just a demo
for
the problem):
BackgroundWorkerInitializeCon
Hi,
I'm trying to write a background writer, and I'm facing a problem with
timestamps. The following code is where I'm having a problem (it's just a demo
for
the problem):
BackgroundWorkerInitializeConnection("test", NULL);
while (!got_sigterm)
{
int ret;
/* Wait 1s */
re
Hi,
While working on the "What's new in 9.2", I think I found a small bug:
SELECT to_date('519-07-02','YYY-MM-DD');
to_date
0519-07-02
(1 row)
It comes, I think, from the year 519 case not being handled in the following
code. Patch attached
+ if (year < 70)
+
On Mon, 2012-04-23 at 10:53 +0200, Boszormenyi Zoltan wrote:
> 2012-04-10 09:02 keltezéssel, Boszormenyi Zoltan írta:
> > 2012-04-06 14:47 keltezéssel, Cousin Marc írta:
> >> On 05/04/12 08:02, Boszormenyi Zoltan wrote:
> >>> 2012-04-04 21:30 keltezéssel, Alvaro Herrera írta:
> I think this pa
2011/9/19 Robert Haas :
> On Mon, Sep 19, 2011 at 12:51 PM, Marc Cousin wrote:
>> Here is my review for EXPLAIN and nfiltered
>> (http://archives.postgresql.org/message-id/4e6e9e83.7070...@2ndquadrant.com)
>
> Please add this review to the CommitFes
Here is my review for EXPLAIN and nfiltered
(http://archives.postgresql.org/message-id/4e6e9e83.7070...@2ndquadrant.com)
- Is the patch in context diff format?
It's in git diff format
- Does it apply cleanly to the current git master?
Yes
- Does it include reasonable tests, necessary doc patches
The Wednesday 17 November 2010 19:41:19, Tom Lane wrote :
> Marc Cousin writes:
> >>> - Does the feature work as advertised?
> >>>
> >>> Yes. It works consistently, isn't fooled by savepoints or multiple
> >>> serials in a table, or con
The Wednesday 17 November 2010 15:50:36, Jaime Casanova wrote :
> On Wed, Nov 17, 2010 at 8:13 AM, Marc Cousin wrote:
> > - Does the feature work as advertised?
> >
> > Yes. It works consistently, isn't fooled by savepoints or multiple
> > serials in a table, o
Hi, Here is my review of 'rollback sequence reset for TRUNCATE ... RESTART
IDENTITY' patch.
- Is the patch in context diff format?
It's in git diff format. I guess it's OK ?
- Does it apply cleanly to the current git master?
Yes
- Does it include reasonable tests, necessary doc patches, etc?
Do
The Saturday 30 October 2010 11:05:17, Andres Freund wrote :
> Hi,
>
> This thread died after me not implementing a new version and some potential
> license problems.
>
> I still think its worthwile (and I used it in production for some time) so
> I would like to implement a version fit for the n
The Monday 02 August 2010 13:59:59, Boszormenyi Zoltan wrote :
> >
> > Also, I made sure that only one or two timeout causes (one of
> > deadlock_timeout
> > and lock_timeout in the first case or statement_timeout plus one of the
> > other two)
> > can be active at a time.
>
> A little clarificati
The Thursday 29 July 2010 13:55:38, Boszormenyi Zoltan wrote :
> I fixed this by adding CheckLockTimeout() function that works like
> CheckStatementTimeout() and ensuring that the same start time is
> used for both deadlock_timeout and lock_timeout if both are active.
> The preference of errors if
Hi, I've been reviewing this patch for the last few days. Here it is :
* Submission review
* Is the patch in context diff format?
Yes
* Does it apply cleanly to the current CVS HEAD?
Yes
* Does it include reasonable tests, necessary doc patches, etc?
Doc patches are there.
There are no reg
2010/2/10 Takahiro Itagaki
>
> Tom Lane wrote:
>
> > Takahiro Itagaki writes:
> > > We have an optimization to bulkload date in pg_restore, but the code
> > > only works in parallel restore (--jobs >= 2). Why don't we do the
> > > same optimization in the serial restore (--jobs = 1) ?
> >
> > T
Another issue with plan caches, besides contention, in Oracle at least, is
shared memory fragmentation (as plans aren't all the same size in memory ...)
But this cache is very helpful for developments where every query is done via
prepare/execute/deallocate. I've seen it a lot on java apps, the
26 matches
Mail list logo
