On 04/05/2012 04:27 PM, Simon Riggs wrote:
It's shocking since after months of work and an especially extended
edition CF, we expect people to deliver something, not just shunt the
whole thing off as rejected with 1 days's notice to alter that
outcome.
I don't think this is being fair to Robert
On lör, 2012-03-24 at 10:01 +, Gianni Ciolli wrote:
> ON (DELETE | UPDATE) actions for EACH foreign keys
> ==
>
> -- --- ---
> |ON |ON |
> Action| DELETE | UPDATE
On fre, 2012-04-06 at 00:25 -0300, Alvaro Herrera wrote:
> Some moments of radical thinking later, I became unhappy with the fact
> that the conninfo stuff and parameter keywords are all crammed in the
> PQconnectdbParams description. This feels wrong to me, even more so
> after we expand it even
Thanks, Hanada-san!
Best regards,
Etsuro Fujita
-Original Message-
From: Shigeru HANADA [mailto:shigeru.han...@gmail.com]
Sent: Friday, April 06, 2012 11:41 AM
To: Etsuro Fujita
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] WIP: Collecting statistics on CSV file data
(2012/04/
On Tue, Apr 3, 2012 at 8:28 AM, Kevin Grittner
wrote:
> Might as well jump in with both feet:
>
> autovacuum_naptime = 1s
> autovacuum_vacuum_threshold = 1
> autovacuum_vacuum_scale_factor = 0.0
>
> If that smooths the latency peaks and doesn't hurt performance too
> much, it's decent evidence tha
On Thu, Apr 5, 2012 at 8:12 PM, Andrew Dunstan wrote:
> Why was this code:
>
> #ifdef WIN32
> if (parallel_init_done && GetCurrentThreadId() != mainThreadId)
> ExitThread(code);
> #endif
>
>
> removed from dumputils.c by commit 5e86c61a7eec0fdc6961493a150159fa8fc63b1c?
> The co
postgres=# select '{}'::integer[] = array[[]]::integer[][];
?column?
--
t
postgres=# select '{}'::integer[] = array[[[]]]::integer[][][];
?column?
--
t
From this point of view, seems N dimensions of empty array all are equivalent.
But the result of array_length of them always
On 6 April 2012 01:22, Thom Brown wrote:
> On 5 April 2012 23:22, Thom Brown wrote:
>> Hi,
>>
>> I attach a patch to correct various system catalog/view definitions in the
>> docs.
>
> I also found a couple typos in completely different sections. (patch attached)
Apologies, that last patch had
On 5 April 2012 23:22, Thom Brown wrote:
> Hi,
>
> I attach a patch to correct various system catalog/view definitions in the
> docs.
I also found a couple typos in completely different sections. (patch attached)
--
Thom
doc_typo_fixes.patch
Description: Binary data
--
Sent via pgsql-hacke
On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane wrote:
> > The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea
> > but I'm not convinced that all the corner-case details have been
> > adequately thought through, and I'm sca
Why was this code:
#ifdef WIN32
if (parallel_init_done && GetCurrentThreadId() != mainThreadId)
ExitThread(code);
#endif
removed from dumputils.c by commit
5e86c61a7eec0fdc6961493a150159fa8fc63b1c? The commit message doesn't
refer to it at all.
I don't understand it
Hi,
I've tried out pg_receivexlog and have noticed that when restarting
the cluster, pg_receivexlog gets cut off... it doesn't keep waiting.
This is surprising as the DBA would have to remember to start
pg_receivexlog up again.
--
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Magnus Hagander writes:
> If anything, we should be changing it to TLSv1 in both client and
> server, since every client out there now should be using that anyway,
> given that the client has been specifying it for a long time.
Huh? libpq isn't every client.
regards, tom
On Fri, 2012-04-06 at 00:02 +0200, Dimitri Fontaine wrote:
> Robert Haas writes:
> > Huh? AFAICS, there are vestiges of the old terminology all over the
> > patch, although some very incomplete renaming has been done. I'm
> > pretty sure you haven't made the firing points consistent either,
> >
Hi,
I attach a patch to correct various system catalog/view definitions in the docs.
Regards
Thom
catalog_doc_fixes.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
Excerpts from Peter Eisentraut's message of jue abr 05 13:52:13 -0300 2012:
> On ons, 2012-03-28 at 01:49 +0300, Alex wrote:
> > Attached is a gzipped v10, complete with the above fixes and fixes to
> > bugs found by Heikki. Documentation and code comments are also
> > finally updated.
>
> The co
Robert Haas writes:
> Huh? AFAICS, there are vestiges of the old terminology all over the
> patch, although some very incomplete renaming has been done. I'm
> pretty sure you haven't made the firing points consistent either,
> although I'd have to spend more time reviewing to be sure of that.
I
On Thu, Apr 5, 2012 at 5:04 PM, Dimitri Fontaine wrote:
> Those changes are about done now.
Huh? AFAICS, there are vestiges of the old terminology all over the
patch, although some very incomplete renaming has been done. I'm
pretty sure you haven't made the firing points consistent either,
alth
On Thu, Apr 5, 2012 at 08:00, Tatsuo Ishii wrote:
>>> Those code fragment judges the return value from
>>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
>>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
>>> when SSL_ERROR_WANT_READ. It seems they a
On Thu, Apr 5, 2012 at 4:27 PM, Simon Riggs wrote:
> On Thu, Apr 5, 2012 at 8:30 PM, Robert Haas wrote:
>>> I am speaking up now as this is the first time I am told I have to wait
>>> another year for this feature to arrive.
>>
>> Really? You've never seen a patch punted to the next release befo
Robert Haas writes:
> I am not interested in relitigating on this thread what has already
> been extensively discussed nearby. Dimitri and I agreed on numerous
> changes to try to make the behavior sane, and those changes were
> suggested and agreed to for good reason. We didn't agree on every
On Thu, Apr 5, 2012 at 1:40 PM, Robert Haas wrote:
> Yep. I think Tom and I and others were all pretty clear that there
> were not enough people reviewing this CommitFest,
Sorry to derail the thread just a little, but I've thought a little
about this and I wonder if part of the problem is just t
On Thu, Apr 5, 2012 at 4:38 PM, Josh Berkus wrote:
> On 4/5/12 12:56 PM, Hannu Krosing wrote:
>>> Really? You've never seen a patch punted to the next release before
>>> > because it wasn't robust enough? Considering that I see your name
>>> > mentioned in the 8.2 release notes, I find that a b
On Thu, Apr 5, 2012 at 3:56 PM, Hannu Krosing wrote:
> On Thu, 2012-04-05 at 15:30 -0400, Robert Haas wrote:
>> On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing wrote:
>> > For me it would be enough to know if the trigger is fired by top-level
>> > command or not.
>>
>> Well, you would have been out
On 4/5/12 12:56 PM, Hannu Krosing wrote:
>> Really? You've never seen a patch punted to the next release before
>> > because it wasn't robust enough? Considering that I see your name
>> > mentioned in the 8.2 release notes, I find that a bit hard to believe.
> I must admit I did check it only oc
On Thu, Apr 5, 2012 at 8:30 PM, Robert Haas wrote:
>> I am speaking up now as this is the first time I am told I have to wait
>> another year for this feature to arrive.
>
> Really? You've never seen a patch punted to the next release before
> because it wasn't robust enough? Considering that I
On Thu, 2012-04-05 at 15:30 -0400, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing wrote:
> > For me it would be enough to know if the trigger is fired by top-level
> > command or not.
>
> Well, you would have been out of luck, then.
It seemed to me you were coming along nicel
On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing wrote:
> For me it would be enough to know if the trigger is fired by top-level
> command or not.
Well, you would have been out of luck, then.
>> - The patch isn't safe if the triggers try to execute DDL on the
>> object being modified. It's not exa
On Thu, 2012-04-05 at 15:07 -0400, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 2:58 PM, Hannu Krosing wrote:
>
> > Would it be possible to put some "command trigger hooks" in a few
> > strategic places so that some trigger-like functionality could be loaded
> > at run time, mainly with a view of w
On Fri, Mar 23, 2012 at 7:41 PM, Marti Raudsepp wrote:
> Yeah, I'm still working on addressing the comments from your last email.
>
> Haven't had much time to work on it for the last 2 weeks, but I hope
> to finish most of it this weekend.
Since the updated patch seems never to have been posted,
On Thu, 2012-04-05 at 15:02 -0400, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 2:46 PM, Hannu Krosing wrote:
> > To me it looked like the scope of the patch started to suddenly expand
> > exponentially a few days ago from a simple COMMAND TRIGGERS, which would
> > have finally enabled trigger-base
Excerpts from Robert Haas's message of jue abr 05 15:40:17 -0300 2012:
>
> On Thu, Apr 5, 2012 at 2:37 PM, Alvaro Herrera
> wrote:
> > The FK locking patch isn't on this list; however, I'm hijacking this
> > thread to say that some benchmarking runs we tried weren't all that
> > great, showing 9
On Thu, Apr 5, 2012 at 2:58 PM, Hannu Krosing wrote:
> On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote:
>> On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
>> > On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs wrote:
>
> ...
>> > > I think doing so will cause substantial misery for many us
On Thu, Apr 5, 2012 at 2:46 PM, Hannu Krosing wrote:
> To me it looked like the scope of the patch started to suddenly expand
> exponentially a few days ago from a simple COMMAND TRIGGERS, which would
> have finally enabled trigger-based or "logical" replication systems to
> do full replication to
On 04/05/2012 02:00 PM, Robert Haas wrote:
I think Andrew is working on parallel pg_dump, so I suspect the rest
of us should stay out of the way. I've also looked at it extensively
and will work on it if Andrew isn't, but I don't think it's ready to
commit. A few preliminary pieces could go i
On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote:
> On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
> > On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs wrote:
...
> > > I think doing so will cause substantial misery for many users. I find
> > > it hard to believe that such a simple concep
On Thu, Apr 05, 2012 at 02:23:03PM -0400, Tom Lane wrote:
> > I think the ECPG fetch patch is about ready to go. Normally Michael
> > Meskes handles all ECPG patches, but I'm not sure what his schedule is
> > like. I'm not sure what the politics are of someone else touching
> > that code.
>
> I
On 25 March 2012 09:17, Simon Riggs wrote:
> The main thing we're waiting on are the performance tests to confirm
> the lack of regression.
I have extensively benchmarked the latest revision of the patch
(tpc-b.sql), which I pulled from Alvaro's github account. The
benchmark was of the feature br
On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs wrote:
> > On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas wrote:
> >> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs wrote:
> >>> These patches aren't marked with a committer
> >>>
> >>> FK arrays
> >>>
On Thu, Apr 5, 2012 at 7:37 PM, Alvaro Herrera
wrote:
> The FK locking patch isn't on this list;
We'd agreed you were the assigned committer, hence not on list.
> however, I'm hijacking this
> thread to say that some benchmarking runs we tried weren't all that
> great, showing 9% performance de
On Thu, Apr 5, 2012 at 2:37 PM, Alvaro Herrera
wrote:
> The FK locking patch isn't on this list; however, I'm hijacking this
> thread to say that some benchmarking runs we tried weren't all that
> great, showing 9% performance degradation on stock pgbench -- i.e. a
> large hit that will harm ever
On Thu, Apr 5, 2012 at 7:23 PM, Tom Lane wrote:
> The FK arrays one I'm kind of queasy about. It's a cool-sounding idea
> but I'm not convinced that all the corner-case details have been
> adequately thought through, and I'm scared of being unable to fix any
> such bugs in later versions because
Excerpts from Simon Riggs's message of jue abr 05 14:28:54 -0300 2012:
> These patches aren't marked with a committer
>
> FK arrays
> ECPG fetch
> foreign stats
> command triggers
> check function
> parallel pg_dump
>
> Does that mean myself or others should be claiming them for commit/reject?
On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane wrote:
> In fact, for *most* of these patches the fact that they're still here
> should give you pause about just committing them.
Um, yeah.
>> I am not sure what the state of the foreign stats patch is, or FK arrays.
>
> I'm taking the foreign stats one;
2012/4/5 Heikki Linnakangas :
> On 05.04.2012 21:00, Robert Haas wrote:
>>
>> Heikki recently produced a revision of the check function patch, but
>> I'm not sure whether he's planning to commit that or whether it's a
>> demonstration of a broader rework he wants Pavel (or someone else) to
>> do.
On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs wrote:
> On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas wrote:
>> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs wrote:
>>> These patches aren't marked with a committer
>>>
>>> FK arrays
>>> ECPG fetch
>>> foreign stats
>>> command triggers
>>> check functio
On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs wrote:
>> These patches aren't marked with a committer
>>
>> FK arrays
>> ECPG fetch
>> foreign stats
>> command triggers
>> check function
>> parallel pg_dump
>>
>> Does that mean myself or others sh
On 4/3/12 11:30 PM, Greg Smith wrote:
On 03/25/2012 04:29 PM, Jim Nasby wrote:
Another $0.02: I don't recall the community using pg_bench much at all to
measure latency... I believe it's something fairly new. I point this out
because I believe there are differences in analysis that you need to
Robert Haas writes:
> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs wrote:
>> These patches aren't marked with a committer
> I think the ECPG fetch patch is about ready to go. Normally Michael
> Meskes handles all ECPG patches, but I'm not sure what his schedule is
> like. I'm not sure what the
On Wed, Mar 28, 2012 at 12:13 PM, Jaime Casanova wrote:
> On Wed, Mar 28, 2012 at 8:47 AM, Robert Haas wrote:
$ ./pg_archivecleanup -x "bz2" /tmp 000100010058
>>>
>>> Hmm, but I thought that the idea was that the extension was optional.
>>> Perhaps I'm missing something but
On 05.04.2012 21:00, Robert Haas wrote:
Heikki recently produced a revision of the check function patch, but
I'm not sure whether he's planning to commit that or whether it's a
demonstration of a broader rework he wants Pavel (or someone else) to
do. At any rate, I think it's up to him whether o
On Thu, Apr 5, 2012 at 9:05 AM, Peter Geoghegan wrote:
> On 3 April 2012 12:11, Robert Haas wrote:
>> Well, for 9.2, I am asking that you rip all that stuff out of the
>> patch altogether so we can focus on the stuff that was in the original
>> patch.
>
> Given how we're pushed for time, I'm incl
On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs wrote:
> These patches aren't marked with a committer
>
> FK arrays
> ECPG fetch
> foreign stats
> command triggers
> check function
> parallel pg_dump
>
> Does that mean myself or others should be claiming them for commit/reject?
I've been right in the
Peter Eisentraut writes:
> The alternatives are now to introduce a new function like has_rows()
> that returns True iff result rows exist and therefore result metadata
> can be fetched, or go back to having coltypes() et al. return None when
> no metadata exists. I'm in favor of the latter, becau
2012/4/5 Peter Eisentraut
> On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
> > >> I said it was a reasonable alternative, not that it was the only one
> > >> we should consider. The behavior of .nrows() mi
These patches aren't marked with a committer
FK arrays
ECPG fetch
foreign stats
command triggers
check function
parallel pg_dump
Does that mean myself or others should be claiming them for commit/reject?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
> >> I said it was a reasonable alternative, not that it was the only one
> >> we should consider. The behavior of .nrows() might be accidental,
> >> but perhaps it
On Thu, Apr 5, 2012 at 12:44 PM, Greg Stark wrote:
> On Thu, Apr 5, 2012 at 3:05 PM, Robert Haas wrote:
>> I'm not sure I find those numbers all that helpful, but there they
>> are. There are a couple of outliers beyond 12 s on the patched run,
>> but I wouldn't read anything into that; the abso
On Thu, Apr 05, 2012 at 12:49:37PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > Minor cleanups:
>
> > * Change callback return value to be 'bool': 0 is error.
> > Currently the accepted return codes are 1 and -1,
> > which is weird.
>
> No, I did it that way intentionally, with the thoug
On Thu, Apr 5, 2012 at 12:30 PM, Jeff Janes wrote:
>> I'm not sure I find those numbers all that helpful, but there they
>> are. There are a couple of outliers beyond 12 s on the patched run,
>> but I wouldn't read anything into that; the absolute worst values
>> bounce around a lot from test to
Robert Haas writes:
> Examining this thread, I think there is insufficient consensus to push
> this patch into 9.2. It's not entirely clear that this patch isn't
> what we want, but it's not entirely clear that it is what we want
> either, and I think it's too late in the release cycle to push
>
On Thu, Apr 5, 2012 at 17:34, Tom Lane wrote:
> Stephen Frost writes:
>> * Andres Freund (and...@anarazel.de) wrote:
>>> Why would pipes be more useful? Its not like you could build useful
>>> pipelines
>>> with them.
>
>> The point is to avoid the risk that someone else could connect to the
>>
On ons, 2012-03-28 at 01:49 +0300, Alex wrote:
> Attached is a gzipped v10, complete with the above fixes and fixes to
> bugs found by Heikki. Documentation and code comments are also
> finally updated.
The compiler warning is still there:
fe-connect.c: In function ‘conninfo_parse’:
fe-connect.c
Marko Kreen writes:
> Minor cleanups:
> * Change callback return value to be 'bool': 0 is error.
> Currently the accepted return codes are 1 and -1,
> which is weird.
No, I did it that way intentionally, with the thought that we might add
back return code zero (or other return codes) in the
On Thu, Apr 5, 2012 at 3:05 PM, Robert Haas wrote:
> I'm not sure I find those numbers all that helpful, but there they
> are. There are a couple of outliers beyond 12 s on the patched run,
> but I wouldn't read anything into that; the absolute worst values
> bounce around a lot from test to test
On Thu, Apr 5, 2012 at 7:05 AM, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 9:29 AM, Greg Stark wrote:
>> On Thu, Apr 5, 2012 at 2:24 PM, Robert Haas wrote:
>>> Sorry, I don't understand specifically what you're looking for. I
>>> provided latency percentiles in the last email; what else do you
On Wed, Apr 04, 2012 at 06:41:00PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Apr 4, 2012 at 10:17 PM, Tom Lane wrote:
> >> Given the lack of consensus around the suspension API, maybe the best
> >> way to get the underlying libpq patch to a committable state is to take
> >> it out
"Albe Laurenz" writes:
> I think that the price of a remote table scan is something
> we should be willing to pay for good local statistics.
> And there is always the option not to analyze the foreign
> table if you are not willing to pay that price.
> Maybe the FDW API could be extended so that
On Thursday, April 05, 2012 06:12:48 PM Tom Lane wrote:
> Andres Freund writes:
> > On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
> >> Yeah, that would be a small pain in the neck, but it eliminates a huge
> >> pile of practical difficulties, like your blithe assumption that you can
> >>
On Tue, Apr 3, 2012 at 4:15 AM, Dimitri Fontaine wrote:
> Tom Lane writes:
>>> On Apr 2, 2012, at 11:24 AM, Peter Eisentraut wrote:
Or an extension could specify itself which version numbering scheme it
uses. This just has to be a reference to a type, which in turn could be
semver
Andres Freund writes:
> On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
>> Yeah, that would be a small pain in the neck, but it eliminates a huge
>> pile of practical difficulties, like your blithe assumption that you can
>> find a "private directory" somewhere (wrong) or disallow access t
On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
> Andres Freund writes:
> >> The point is to avoid the risk that someone else could connect to the
> >> database at the same time you're doing work on it.
> >
> > I got that. I just fail to see what the advantage of using two pipes
> > inste
On Wed, Mar 28, 2012 at 7:23 AM, Robert Haas wrote:
> Although I liked the idea of separating this out, I wasn't thinking we
> should do it as part of this patch. It seems like an independent
> project. At any rate, I strongly agree that counting the number of
> strategy allocations is not real
On Tue, Mar 27, 2012 at 8:30 PM, Robert Haas wrote:
> On Tue, Mar 27, 2012 at 3:22 PM, Ants Aasma wrote:
>> On Tue, Mar 27, 2012 at 9:58 PM, Robert Haas wrote:
>>> I've committed the core of this. I left out the stats collector
>>> stuff, because it's still per-table and I think perhaps we shou
Andres Freund writes:
>> The point is to avoid the risk that someone else could connect to the
>> database at the same time you're doing work on it.
> I got that. I just fail to see what the advantage of using two pipes instead
> of one socket as every other plain connection would be?
Yeah, tha
Stephen Frost writes:
> * Andres Freund (and...@anarazel.de) wrote:
>> Why would pipes be more useful? Its not like you could build useful
>> pipelines
>> with them.
> The point is to avoid the risk that someone else could connect to the
> database at the same time you're doing work on it.
Rig
Hi,
Not sure if were just missing each others point?
On Thursday, April 05, 2012 05:20:04 PM Stephen Frost wrote:
> > Why would pipes be more useful? Its not like you could build useful
> > pipelines with them.
>
> The point is to avoid the risk that someone else could connect to the
> database
* Andres Freund (and...@anarazel.de) wrote:
> Hm. Changing libpq to use two pipes at the same time sounds considerably more
> invasive than basically just changing the socket creation and some minor
> details.
It's not something we'd back-patch, but I don't believe it'd be very
difficult to impl
On Thursday, April 05, 2012 04:44:11 PM Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > I wonder if it wouldn't be better to pass a named pipe under windows and
> > use a AF_UNIX socket everwhere else. Both should be pretty easily usable
> > with the existing code. PG already
* Andres Freund (and...@anarazel.de) wrote:
> I wonder if it wouldn't be better to pass a named pipe under windows and use
> a
> AF_UNIX socket everwhere else. Both should be pretty easily usable with the
> existing code. PG already seems to use named pipes under windows, so...
I didn't think T
On Thursday, April 05, 2012 03:46:54 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane wrote:
> >> Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
> >> talking to a standalone backend, but nobody's gotten round to making
> >> that poss
On Thu, Apr 5, 2012 at 9:29 AM, Greg Stark wrote:
> On Thu, Apr 5, 2012 at 2:24 PM, Robert Haas wrote:
>> Sorry, I don't understand specifically what you're looking for. I
>> provided latency percentiles in the last email; what else do you want?
>
> I think he wants how many waits were there tha
Yeb Havinga writes:
> On 2012-04-04 17:10, Tom Lane wrote:
>> I think a better way would be to temporarily set
>> plpgsql_IdentifierLookup to IDENTIFIER_LOOKUP_DECLARE,
> Thank you for looking at it. Attached is a patch that implements your
> suggestion.
Oh, sorry, I assumed you'd seen that I c
Robert Haas writes:
> On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane wrote:
>> Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
>> talking to a standalone backend, but nobody's gotten round to making
>> that possible.
> Are you thinking about something like postgres --single
>
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane wrote:
> Stephen Frost writes:
>> The single-user option *sounds* viable, but, iirc, it actually isn't due
>> to the limitations on what can be done in that mode.
>
> Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
> talking to a
On Thu, Apr 5, 2012 at 2:24 PM, Robert Haas wrote:
> Sorry, I don't understand specifically what you're looking for. I
> provided latency percentiles in the last email; what else do you want?
I think he wants how many waits were there that were between 0 and 1s
how many between 1s and 2s, etc. M
On Thu, Apr 5, 2012 at 8:30 AM, Simon Riggs wrote:
> On Thu, Apr 5, 2012 at 12:56 PM, Robert Haas wrote:
>
>> Overall tps, first without and then with patch:
>>
>> tps = 14546.644712 (including connections establishing)
>> tps = 14550.515173 (including connections establishing)
>>
>> TPS graphs b
On 3 April 2012 12:11, Robert Haas wrote:
> Well, for 9.2, I am asking that you rip all that stuff out of the
> patch altogether so we can focus on the stuff that was in the original
> patch.
Given how we're pushed for time, I'm inclined to agree that that is
the best course of action.
Attached
Sorry, I sent this email without noticing Hanada-san' earlier email. So,
please look at Hanada-san's post.
Best regards,
Etsuro Fujita
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
Sent: Thursday, April
At 22:11 12/03/28 +0900, Shigeru HANADA wrote:
ANALYZE support for foreign tables is proposed by Fujita-san in current
CF, so I'd like to push it.
I updated the patch to the latest HEAD. Please find attached a patch.
Best regards,
Etsuro Fujita
postgresql-analyze-v7.patch
Description: Binar
On Thu, Apr 5, 2012 at 12:56 PM, Robert Haas wrote:
> Overall tps, first without and then with patch:
>
> tps = 14546.644712 (including connections establishing)
> tps = 14550.515173 (including connections establishing)
>
> TPS graphs by second attached.
Again, I'm not that fussed about throughp
On Thu, Apr 5, 2012 at 5:41 AM, Simon Riggs wrote:
> I'm also loathe to back patch. But its not very often we find a
> problem that causes all backends to wait behind a single I/O.
You have a point.
Meanwhile, here are the benchmark results you requested. I did half
hour runs with -l. Here are
Hello
2012/4/4 Heikki Linnakangas :
> On 04.04.2012 19:32, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>>
>>> I don't think I'm getting my point across by explaining, so here's a
>>> modified version of the patch that does what I was trying to say.
>>
>>
>> Minor side point: some of the dif
On Thu, Apr 5, 2012 at 12:25 AM, Robert Haas wrote:
>> That seems much smarter. I'm thinking this should be back patched
>> because it appears to be fairly major, so I'm asking for some more
>> certainty that every thing you say here is valid. No doubt much of it
>> is valid, but that's not enoug
On Thu, Apr 5, 2012 at 1:23 AM, Robert Haas wrote:
> I don't think we're micro-optimizing, either. I don't consider
> avoiding a 10-second cessation of all database activity to be a
> micro-optimization even on a somewhat artificial benchmark.
Robert is not skewing the SLRU mechanism towards th
On 2012-04-04 17:10, Tom Lane wrote:
Yeb Havinga writes:
Using a cursor argument name equal to another plpgsql variable results
in the error:
cursor .. has no argument named ""
I think a better way would be to temporarily set
plpgsql_IdentifierLookup to IDENTIFIER_LOOKUP_DECLARE, so as to supp
96 matches
Mail list logo
