Any progress on this?
---
Brendan Jurd wrote:
> On 18 October 2010 01:19, Tom Lane wrote:
> > Brendan Jurd writes:
> >> On 17 October 2010 09:59, Tom Lane wrote:
> >>> Good point. ?Maybe the correct fix is to remember whe
Robert Haas wrote:
> > Actually, we *do* have some idea which tables are hot. ?Or at least, we
> > could. ? Currently, pg_stats for tables are "timeless"; they just
> > accumulate from the last reset, which has always been a problem in
> > general for monitoring. ?If we could make top-level table a
Josh Berkus wrote:
>
> > Right now pg_options_to_table() is not documented. Should it be?
>
> Yes, I think so.
Done, with the attached, applied patch.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for ever
Marko Tiikkaja writes:
> On 2011-02-25 4:58 PM, Tom Lane wrote:
>> Specifically, I'm imagining getting rid of the patch's additions to
>> InitPlan and ExecutePlan that find all the modifying sub-queries and
>> force them to be cycled to completion before the main plan runs.
>> Just run the main pl
On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> Yay! I'm excited about this, particularly the possible "pipelining"
>> stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
>> have it be like cool and fast and stuff.
>
>> Or at least I hope you can do t
Robert Haas writes:
> Yay! I'm excited about this, particularly the possible "pipelining"
> stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
> have it be like cool and fast and stuff.
> Or at least I hope you can do that.
It's gonna need some work yet. As things stand, the
On Fri, Feb 25, 2011 at 6:41 PM, Josh Berkus wrote:
>> One idea Tom and I kicked around previously is to set an assumed
>> caching percentage for each table based on its size relative to
>> effective_cache_size - in other words, assume that the smaller a table
>> is, the more of it will be cached.
On Fri, Feb 25, 2011 at 2:26 PM, Alvaro Herrera
wrote:
> Excerpts from Rod Taylor's message of vie feb 25 14:03:58 -0300 2011:
>
>> How practical would it be for analyze to keep a record of response times for
>> given sections of a table as it randomly accesses them and generate some
>> kind of a
On Fri, Feb 25, 2011 at 7:00 PM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
>>> OK, I will make those adjustments. Are you going to do more work on the
>>> documentation part of the patch? I can stick to working on the code
>>> part meanwhile, if yo
On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański wrote:
> On 15/02/11 20:39, Peter Eisentraut wrote:
>> On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
>>> Because the invocation that actually recurses sets up the scene for
>>> failure.
>>
>> That's what we're observing, but I can't figure out
Robert Haas writes:
> Tom/Alvaro, have the two of you hammered out who is going to finish
> this one off? I *believe* Alvaro told me on IM that he was leaving
> this one for Tom.
Last I heard, the ball was in my court. I'll try to get it done over
the weekend.
regards,
On Wed, Feb 9, 2011 at 5:22 PM, Peter Eisentraut wrote:
> On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote:
>> On 11-02-06 11:40 AM, Jan Urbański wrote:
>>
>> > PFA an updated patch with documentation.
>>
>> > Yeah, changed them.
>>
>> Those changes look fine. The tests now pass.
>>
>> I've
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wrote:
> On 24/02/11 14:10, Peter Eisentraut wrote:
>> On tor, 2010-12-23 at 14:56 +0100, Jan Urbański wrote:
>>> For errors originating from Python exceptions add the traceback as the
>>> message detail. The patch tries to mimick Python's traceback.py
On Thu, Feb 24, 2011 at 11:02 AM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> On 2011-02-24 5:21 PM, Tom Lane wrote:
>>> Oh, did we decide to do it that way? OK with me, but the submitted docs
>>> are woefully inadequate on the point. This behavior is going to have to
>>> be explained extremely
On Thu, Feb 24, 2011 at 9:06 AM, Robert Haas wrote:
> On Thu, Feb 24, 2011 at 8:13 AM, Shigeru HANADA
> wrote:
>>
>> On Wed, 23 Feb 2011 20:30:05 +0900
>> Shigeru HANADA wrote:
>>
>>>
>>> On Tue, 22 Feb 2011 11:33:25 -0500
>>> Robert Haas wrote:
>>> > Is anyone actually working on a new version
I wrote:
> The first solution that comes to mind is to pay attention to the
> interdependencies of the CTEs, and perform the cleanup in an appropriate
> order (here, the ModifyTable for y needs to be cycled first).
Doh ... actually, we already *are* ordering the CTEs in dependency
order, so it's a
David Fetter writes:
> Sorry that was unclear. Let's imagine there's a DELETE ... RETURNING
> in one WITH, and an UPDATE in another that depends on that one. Is
> that still allowed?
Yeah it is, although I just noticed that there's a bug in the new
implementation:
with t1 as (insert into x sel
On Fri, Feb 25, 2011 at 10:12:02PM -0500, Tom Lane wrote:
> David Fetter writes:
> > What's the effect, if any, on CTEs that depend on each other
> > explicitly?
>
> An error. That would require mutual recursion, which we don't
> support for the SELECT case let alone data-modifying statements.
David Fetter writes:
> What's the effect, if any, on CTEs that depend on each other
> explicitly?
An error. That would require mutual recursion, which we don't
support for the SELECT case let alone data-modifying statements.
regards, tom lane
--
Sent via pgsql-hackers
On Thu, Feb 24, 2011 at 11:35:30AM -0800, David Wheeler wrote:
> On Feb 24, 2011, at 10:43 AM, Robert Haas wrote:
>
> >> The best idea I have at the moment is to spell out "data modifying
> >> command" (or "statement") rather than relying on the acronym.
> >> In the code, we could change hasDmlWit
On Thu, Feb 24, 2011 at 11:20:48AM -0500, Tom Lane wrote:
> The wCTE patch refers to the feature it's adding as "DML WITH". I'm
> still pretty unhappy with that terminology. In my view of the world,
> "DML" includes SELECT as well as INSERT/UPDATE/DELETE. The wikipedia
> entry about the term
> h
On Fri, Feb 25, 2011 at 09:58:36AM -0500, Tom Lane wrote:
> I had what seems to me a remarkably good idea, though maybe someone else
> can spot a problem with it. Given that we've decided to run the
> modifying sub-queries all with the same command counter ID, they are
> logically executing "in pa
Marko Tiikkaja writes:
> On 2011-02-26 2:00 AM, Tom Lane wrote:
>> I've gone ahead and applied the code portion of the patch, with
>> modifications as per discussion, and other editorialization.
> Thanks a lot!
> One thing bothers me though: what was the reason for requiring a
> RETURNING claus
On 2011-02-26 2:00 AM, Tom Lane wrote:
I've gone ahead and applied the code portion of the patch, with
modifications as per discussion, and other editorialization.
Thanks a lot!
One thing bothers me though: what was the reason for requiring a
RETURNING clause for data-modifying statements in
On Fri, Feb 25, 2011 at 5:21 PM, Josh Berkus wrote:
> On 2/25/11 4:57 PM, Jeff Davis wrote:
>> On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
>>> Hmmm, I don't follow this. The user can only disable syncrep for their
>>> own transactions. If they don't care about the persistence of their
On Fri, Feb 25, 2011 at 4:52 PM, Jeff Davis wrote:
> On Wed, 2011-02-23 at 22:42 -0800, Daniel Farina wrote:
>> Oh, yes, this reproduces past shutdowns/startups, and there's quite a
>> few txids before I catch up. I'm also comfortable poking around with
>> gdb (I have already recompiled with debug
On 2/25/11 4:57 PM, Jeff Davis wrote:
> On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
>> Hmmm, I don't follow this. The user can only disable syncrep for their
>> own transactions. If they don't care about the persistence of their
>> transaction post-failover, why should the DBA care?
>
On Wed, 2011-02-23 at 22:42 -0800, Daniel Farina wrote:
> Oh, yes, this reproduces past shutdowns/startups, and there's quite a
> few txids before I catch up. I'm also comfortable poking around with
> gdb (I have already recompiled with debugging symbols and
> optimizations off and was poking aroun
On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
> Hmmm, I don't follow this. The user can only disable syncrep for their
> own transactions. If they don't care about the persistence of their
> transaction post-failover, why should the DBA care?
I think that's the difference between failov
On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus wrote:
> Daniel,
>
>> Ah, okay, I had missed that discussion, I also did not know it got so
>> specific as to address this case (are you sure?) rather than something
>> more general, say quorum or N-safe durability.
>
> The way we address that case is t
Daniel,
> Ah, okay, I had missed that discussion, I also did not know it got so
> specific as to address this case (are you sure?) rather than something
> more general, say quorum or N-safe durability.
The way we address that case is through n-safe durability.
> The user may have their own level
On Fri, Feb 25, 2011 at 3:44 PM, Josh Berkus wrote:
>
>> Right now, as it stands, the syncrep patch will be happy as soon as
>> the data has been fsynced to either B or A-prime; I don't think we can
>> guarantee at any point that A-prime can become the leader, and feed B.
>
> Yeah, I think that's
Marko Tiikkaja writes:
> On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
>> OK, I will make those adjustments. Are you going to do more work on the
>> documentation part of the patch? I can stick to working on the code
>> part meanwhile, if you are.
> I am planning on working on the documentation
> Right now, as it stands, the syncrep patch will be happy as soon as
> the data has been fsynced to either B or A-prime; I don't think we can
> guarantee at any point that A-prime can become the leader, and feed B.
Yeah, I think that's something we said months ago is going to be a 9.2
feature, n
> 4. Even if we could accurately estimate the percentage of the table
> that is cached, what then? For example, suppose that a user issues a
> query which retrieves 1% of a table, and we know that 1% of that table
> is cached. How much of the data that the user asked for is cache?
FWIW, for a m
2011/2/25 Robert Haas :
> 2011/2/25 Cédric Villemain :
>>> All that having been said, I think that while Josh is thinking fuzzily
>>> about the mathematics of his proposal, the basic idea is pretty
>>> sensible. It is not easy - likely not possible - for the system to
>>> have a good idea which th
On Fri, Feb 25, 2011 at 2:33 PM, Daniel Farina wrote:
> I know I got hit by a backend synchronization (in the sense of locks,
> etc) bugs; do you think it is possible yours (sending SIGSTOP) could
> be the same root cause? I haven't followed all the other bugs cleared
> up by inspection.
I believ
Excerpts from Tom Lane's message of mar feb 15 12:42:00 -0300 2011:
> Heikki Linnakangas writes:
> > pageinspect is just a debugging aid, so I think we should change it from
> > smallint to int4 in 9.1, and not bother backporting.
>
> I don't see any reason that the old version of the function
On Fri, Feb 25, 2011 at 22:58, Dave Page wrote:
> On Fri, Feb 25, 2011 at 9:54 PM, Andrew Dunstan wrote:
>>
>>
>> On 02/25/2011 02:32 PM, Peter Eisentraut wrote:
>>>
>>> According to the online documentation, the APIs are there:
>>> http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
>>>
>>> No
On Fri, Feb 25, 2011 at 9:54 PM, Andrew Dunstan wrote:
>
>
> On 02/25/2011 02:32 PM, Peter Eisentraut wrote:
>>
>> According to the online documentation, the APIs are there:
>> http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
>>
>> Now we'd need someone brave try to make it work. The startin
On 02/25/2011 02:32 PM, Peter Eisentraut wrote:
According to the online documentation, the APIs are there:
http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
Now we'd need someone brave try to make it work. The starting point
would be to define HAVE_LOCALE_T and then make it build. Micros
According to the online documentation, the APIs are there:
http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
Now we'd need someone brave try to make it work. The starting point
would be to define HAVE_LOCALE_T and then make it build. Microsoft has
all the relevant functions and types with an
On Fri, Feb 25, 2011 at 10:41 AM, Yeb Havinga wrote:
>>
> I also did some initial testing on this patch and got the queue related
> errors with > 1 clients. With the code change from Jaime above I still got a
> lot of 'not on queue warnings'.
>
> I tried to understand how the queue was supposed to
On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas wrote:
> On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina wrote:
>> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith wrote:
>>> Robert Haas wrote:
>
> 2. Synchronous replication. Splitting up this patch has allowed some
>>> On top of 4 listed revie
Excerpts from Rod Taylor's message of vie feb 25 14:03:58 -0300 2011:
> How practical would it be for analyze to keep a record of response times for
> given sections of a table as it randomly accesses them and generate some
> kind of a map for expected response times for the pieces of data it is
>
On Fri, Feb 25, 2011 at 5:25 AM, marcin mank wrote:
> On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina wrote:
>>
>> Right now, as it stands, the syncrep patch will be happy as soon as
>> the data has been fsynced to either B or A-prime; I don't think we can
>> guarantee at any point that A-prime ca
Greg Stark writes:
> On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane wrote:
>> However, the real reason for doing it isn't any of those, but rather
>> to establish the principle that the executions of the modifying
>> sub-queries are interleaved not sequential.
> Does the interleaved execution have sa
2011/2/25 Cédric Villemain :
>> All that having been said, I think that while Josh is thinking fuzzily
>> about the mathematics of his proposal, the basic idea is pretty
>> sensible. It is not easy - likely not possible - for the system to
>> have a good idea which things will be in some kind of c
On Fri, Feb 25, 2011 at 11:31 AM, Greg Stark wrote:
> On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane wrote:
>> However, the real reason for doing it isn't any of those, but rather
>> to establish the principle that the executions of the modifying
>> sub-queries are interleaved not sequential. We're n
On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane wrote:
> However, the real reason for doing it isn't any of those, but rather
> to establish the principle that the executions of the modifying
> sub-queries are interleaved not sequential. We're never going to be
> able to do any significant optimization
Marko Tiikkaja writes:
> On 2011-02-25 6:12 PM, Tom Lane wrote:
>> The current implementation with everything in one plantree
>> really ought to look just like a SELECT so far as the portal code
>> is concerned.
> The problem was that the old code was using PORTAL_MULTI_QUERY whenever
> a wCTE w
> 4. Even if we could accurately estimate the percentage of the table
> that is cached, what then? For example, suppose that a user issues a
> query which retrieves 1% of a table, and we know that 1% of that table
> is cached. How much of the data that the user asked for is cache?
> Hard to say,
2011/2/25 Robert Haas :
> On Fri, Feb 25, 2011 at 1:33 AM, Bruce Momjian wrote:
>> Josh Berkus wrote:
>>> On 2/23/11 7:10 AM, Robert Haas wrote:
>>> > IME, most bad query plans are caused by either incorrect
>>> > estimates of selectivity, or wrongheaded notions about what's likely
>>> > to be cac
Daniel Farina wrote:
Server A syncreps to Server B
Now I want to provision server A-prime, which will eventually take the
place of A.
Server A syncreps to Server B
Server A syncreps to Server A-prime
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced
On 2011-02-25 6:12 PM, Tom Lane wrote:
Marko Tiikkaja writes:
Without hacking it broke when PQdescribePrepared was called on a
prepared query like:
WITH t AS (DELETE FROM foo)
SELECT 1;
Not sure if that's an actual problem, but it seemed like something worht
fixing.
I can't replicate su
Marko Tiikkaja writes:
> On 2011-02-25 1:36 AM, Tom Lane wrote:
>> Why is it necessary to hack the portal logic at all? The patch seems to
>> work for me without that. (I've fixed quite a few bugs though, so maybe
>> what this is really doing is masking a problem elsewhere.)
> Without hacking i
On 2011-02-25 4:58 PM, Tom Lane wrote:
Specifically, I'm imagining getting rid of the patch's additions to
InitPlan and ExecutePlan that find all the modifying sub-queries and
force them to be cycled to completion before the main plan runs.
Just run the main plan and let it pull tuples from the C
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Given that we've decided to run the modifying sub-queries all with
>> the same command counter ID, they are logically executing "in
>> parallel".
>> Just run the main plan and let it pull tuples from the CTEs as
>> needed.
> On the face of it, tha
On 2011-02-22 20:43, Jaime Casanova wrote:
you can make this happen more easily, i just run "pgbench -n -c10 -j10
test" and qot that warning and sometimes a segmentation fault and
sometimes a failed assertion
and the problematic code starts at
src/backend/replication/syncrep.c:277, here my sugg
Tom Lane wrote:
> Given that we've decided to run the modifying sub-queries all with
> the same command counter ID, they are logically executing "in
> parallel".
> Just run the main plan and let it pull tuples from the CTEs as
> needed.
On the face of it, that sounds like it has another bene
On Fri, Feb 25, 2011 at 9:58 AM, Tom Lane wrote:
> I had what seems to me a remarkably good idea, though maybe someone else
> can spot a problem with it. Given that we've decided to run the
> modifying sub-queries all with the same command counter ID, they are
> logically executing "in parallel".
I had what seems to me a remarkably good idea, though maybe someone else
can spot a problem with it. Given that we've decided to run the
modifying sub-queries all with the same command counter ID, they are
logically executing "in parallel". The current implementation takes no
advantage of that fa
On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina wrote:
>
> Right now, as it stands, the syncrep patch will be happy as soon as
> the data has been fsynced to either B or A-prime; I don't think we can
> guarantee at any point that A-prime can become the leader, and feed B.
>
- start A` up, replicat
On Fri, Feb 25, 2011 at 1:33 AM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> On 2/23/11 7:10 AM, Robert Haas wrote:
>> > IME, most bad query plans are caused by either incorrect
>> > estimates of selectivity, or wrongheaded notions about what's likely
>> > to be cached. If we could find a way, a
On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina wrote:
> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith wrote:
>> Robert Haas wrote:
2. Synchronous replication. Splitting up this patch has allowed some
>> On top of 4 listed reviewers I know Dan Farina is poking at the last update,
>> so w
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith wrote:
> Robert Haas wrote:
>>>
>>> 2. Synchronous replication. Splitting up this patch has allowed some
> On top of 4 listed reviewers I know Dan Farina is poking at the last update,
> so we may see one more larger report on top of what's already show
66 matches
Mail list logo
