On 19/01/12 17:39, Greg Smith wrote:
> On 1/19/12 1:10 PM, Robert Haas wrote:
> >I have to say that I find that intensely counterintuitive. The
> >current settings are not entirely easy to tune correctly, but at least
> >they're easy to explain.
>
> If there's anyone out there who has run a large
On Sun, Jan 22, 2012 at 8:42 PM, Robert Haas wrote:
> On Sun, Jan 22, 2012 at 3:20 PM, Daniel Farina wrote:
>> A few anecdotes does not constitute evidence, but it does look like
>> some people pay attention to any additional versioning foothold they
>> can get.
>
> Sure, but just because some pe
On Mon, Jan 23, 2012 at 4:58 PM, Simon Riggs wrote:
> On Mon, Jan 16, 2012 at 12:45 PM, Fujii Masao wrote:
>
Please add the Apply mode.
>>>
>>> OK, will do.
>>
>> Done. Attached is the updated version of the patch.
>
> I notice that the Apply mode isn't fully implemented. I had in mind
> tha
* Ants Aasma:
> I had a run in with this. JDBC driver versions < 9.0 with the default
> configuration resulted in silent data corruption. The fix was easy, but not
> having an useful error was what really bothered me.
Same for the DBD::Pg driver.
In this particular case, I knew that the change w
On Mon, Jan 23, 2012 at 9:02 AM, Fujii Masao wrote:
> On Mon, Jan 23, 2012 at 4:58 PM, Simon Riggs wrote:
>> On Mon, Jan 16, 2012 at 12:45 PM, Fujii Masao wrote:
>>
> Please add the Apply mode.
OK, will do.
>>>
>>> Done. Attached is the updated version of the patch.
>>
>> I notice
On Sat, Jan 21, 2012 at 9:20 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Thank you for reviewing this patch!
>
> Hitoshi Harada writes:
>> The patch applies with one reject, which I could fix easily. The make
>> check passed.
>
> Bitrot happens fast in this season… will produce another version of the
Hitoshi Harada writes:
>>> "pg_extension_feature_index" UNIQUE, btree (extoid, extfeature)
> Do you mean you want UNIQUE constraint by this index? I found the
> usage is to search feature by (only) its name, so I wondered if extoid
> is not necessary.
I guess you're right and that's something
On Mon, Jan 23, 2012 at 6:28 PM, Simon Riggs wrote:
> On Mon, Jan 23, 2012 at 9:02 AM, Fujii Masao wrote:
>> On Mon, Jan 23, 2012 at 4:58 PM, Simon Riggs wrote:
>>> On Mon, Jan 16, 2012 at 12:45 PM, Fujii Masao wrote:
>>>
>> Please add the Apply mode.
>
> OK, will do.
Done
Hi,
Any ideas on this?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pgstat-wait-timeout-tp5078125p5165651.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Fri, Jan 20, 2012 at 11:34 PM, Simon Riggs wrote:
> On Fri, Jan 20, 2012 at 12:54 PM, Fujii Masao wrote:
>> Thanks for the review!
>>
>> On Fri, Jan 20, 2012 at 8:15 PM, Simon Riggs wrote:
>>> I'm looking at this patch and wondering why we're doing so many
>>> press-ups to ensure full_page_wr
> Is it such a bad idea to store the literal text of the extension's
> pieces (control file and corresponding SQL program) in catalogs? I'm
> not sure if I understand why everyone is so interested in a special
> interaction with the file system in some way. By the same token,
> extensions can be
Tom Lane writes:
> On reflection it seems like this patch is simply offering the wrong
> solution for the problem. I agree that it could be useful to install
> extensions without having direct access to the server's filesystem,
> but it doesn't seem to follow that we must lobotomize existing exte
Dear pgdevs,
I've just completed the final version of a survey of database schema quality in
open source software. The survey covers 512 projects which use MySQL and/or
PostgreSQL for storing their data. Automatic analyses are performed by querying
the information schema. Statistical validations
Le 23 janvier 2012 11:53, Dimitri Fontaine a écrit :
> Tom Lane writes:
>> On reflection it seems like this patch is simply offering the wrong
>> solution for the problem. I agree that it could be useful to install
>> extensions without having direct access to the server's filesystem,
>> but it
On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
- What happens if DROP EXTENSION ... CASCADE? Does it work?
>>>
>>> It should, what happens when you try? :)
>>
>> I just tried DROP EXTENSION now, and found it broken :(
>>
>> db1=# create extension kmeans;
>>
On Sat, Jan 21, 2012 at 1:52 PM, Marc Mamin wrote:
>> >
>> > c. Refine error handling of dblink.c. I think it preserves the
>> > previous behavior for column number mismatch and type
>> > conversion exception.
>
> Hello,
>
> I don't know if this cover following issue.
> I just mention it for
On Thu, Jan 19, 2012 at 1:58 AM, Hitoshi Harada wrote:
> On Wed, Jan 18, 2012 at 1:11 AM, Hitoshi Harada wrote:
>> On Sat, Jan 14, 2012 at 8:10 AM, Matthew Draper wrote:
>>>
>>> I just remembered to make time to advance this from WIP to proposed
>>> patch this week... and then worked out I'm rud
On 2012-01-13 21:14, Frederico wrote:
Hi folks.
Is there any restriction in create and start threads inside Postgres?
I'm trying to develop a multithread planner, and some times is raised a
exception of access memory.
I'm debugging the code to see if is a bug in the planner, but until now, I
On Fri, Jan 20, 2012 at 7:50 PM, Fujii Masao wrote:
> On Fri, Jan 20, 2012 at 7:38 PM, Simon Riggs wrote:
>> On Fri, Jan 20, 2012 at 3:43 AM, Fujii Masao wrote:
>>
>> Requested update
>
> Thanks! Will review.
In StartChildProcess(), the code which emits an error when fork of walrestore
fails is
On Mon, Jan 23, 2012 at 10:03 AM, Fujii Masao wrote:
>>> To make the walreceiver call WaitLatchOrSocket(), we would need to
>>> merge it and libpq_select() into one function. But the former is the backend
>>> function and the latter is the frontend one. Now I have no good idea to
>>> merge them c
On Mon, Jan 23, 2012 at 5:53 AM, Dimitri Fontaine
wrote:
>> Probably the worst issue with that is that in typical installations,
>> the share/extension/ directory would be read-only to the server, and a
>> lot of people might be uncomfortable with making it writable. Not sure
>> whether we should
On Mon, Jan 23, 2012 at 12:23 PM, Fujii Masao wrote:
> I've not reviewed the patch enough yet. Will review the patch tomorrow again.
Thanks very much. I'm sure that's enough to keep me busy a few days.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Mon, Jan 23, 2012 at 12:12 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 21, 2012 at 5:29 PM, Jim Nasby wrote:
>>> We should also look at having the freelist do something useful, instead of
>>> just dropping it completely. Unfortunately that's probably more work...
>
>> That's kin
On Mon, Jan 23, 2012 at 1:38 AM, Kohei KaiGai wrote:
> What options are available to see rate of workloads of components
> within a particular query?
I usually use oprofile, though I'm given to understand it's been
superseded by a new tool called perf. I haven't had a chance to
experiment with p
On Mon, Jan 23, 2012 at 10:29 AM, Fujii Masao wrote:
> On Fri, Jan 20, 2012 at 11:34 PM, Simon Riggs wrote:
>> On Fri, Jan 20, 2012 at 12:54 PM, Fujii Masao wrote:
>>> Thanks for the review!
>>>
>>> On Fri, Jan 20, 2012 at 8:15 PM, Simon Riggs wrote:
I'm looking at this patch and wondering
On Mon, Jan 23, 2012 at 5:29 AM, Fujii Masao wrote:
> If many people think the patch is not acceptable without such a safeguard,
> I will do that right now.
That's my view. I think we ought to resolve this issue before commit,
especially since it seems unclear that we know how to fix it.
--
Ro
On Mon, Jan 23, 2012 at 8:11 AM, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 5:29 AM, Fujii Masao wrote:
>> If many people think the patch is not acceptable without such a safeguard,
>> I will do that right now.
>
> That's my view. I think we ought to resolve this issue before commit,
> especia
On Mon, Jan 23, 2012 at 1:06 PM, Robert Haas wrote:
> It's pretty trivial to prove that there is a very serious problem with
> BufFreelistLock. I'll admit I can't prove what the right fix is just
> yet, and certainly measurement is warranted.
I agree there is a problem with BufFreelistLock (so
Robert Haas writes:
> "virtual directory" - e.g. CREATE TABLE pg_extension_virtualdir
> (filename text, content text) which would be modifiable by the DBA and
> would be searched either before or after the filesystem itself. This
> catalog wouldn't be dumped by pg_dump, and there would be no chan
On Sun, Jan 22, 2012 at 3:48 PM, Kohei KaiGai wrote:
> I tried to implement a fdw module that is designed to utilize GPU
> devices to execute
> qualifiers of sequential-scan on foreign tables managed by this module.
>
> It was named PG-Strom, and the following wikipage gives a brief
> overview of
There was finally some time available on Nate Boley's server, which he
has been kind enough to make highly available for performance testing
throughout this cycle, and I got a chance to run some benchmarks
against a bunch of the perfomance-related patches in the current
CommitFest. Specifically, I
On Mon, Jan 23, 2012 at 8:25 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> "virtual directory" - e.g. CREATE TABLE pg_extension_virtualdir
>> (filename text, content text) which would be modifiable by the DBA and
>> would be searched either before or after the filesystem itself. This
>> c
On Mon, Jan 23, 2012 at 4:03 AM, Florian Weimer wrote:
> * Ants Aasma:
>> I had a run in with this. JDBC driver versions < 9.0 with the default
>> configuration resulted in silent data corruption. The fix was easy, but not
>> having an useful error was what really bothered me.
>
> Same for the DBD
On Mon, Jan 23, 2012 at 1:53 PM, Robert Haas wrote:
> Results are the median of three five-minute test runs
> checkpoint_timeout = 15min
Test duration is important for tests that don't relate to pure
contention reduction, which is every patch apart from XLogInsert.
We've discussed that before,
* Robert Haas:
>> In this particular case, I knew that the change was coming and could
>> push updated Java and Perl client libraries well before the server-side
>> change hit our internal repository, but I really don't want to have to
>> pay attention to such details.
>
> But if we *don't* turn t
2012/1/23 Simon Riggs :
> On Sun, Jan 22, 2012 at 3:48 PM, Kohei KaiGai wrote:
>
>> I tried to implement a fdw module that is designed to utilize GPU
>> devices to execute
>> qualifiers of sequential-scan on foreign tables managed by this module.
>>
>> It was named PG-Strom, and the following wiki
On Mon, Jan 23, 2012 at 2:49 PM, Kohei KaiGai wrote:
>> Also, the query you mention is probably the best performing query you
>> can come up with. It looks like a GIS query, yet isn't. Would it be
>> possible to run tests on the TPC-H suite and do a full comparison of
>> strengths/weaknesses so w
On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen
wrote:
> * introduced a new GUC variable array_output copying the current
> bytea_output type, with values "full" (old value) and
> "smallfixed" (new default)
> * added documentation for the new GUC variable
If this variable changes protocol-leve
On Tue, Jan 3, 2012 at 7:49 PM, Pavel Stehule wrote:
> I change a patch and now ALTER TABLE, ALTER INDEX, ALTER SEQUENCE and
> ALTER VIEW has IF EXISTS clause
Patch no longer applies. Pls update.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
Robert Haas writes:
> I am pretty concerned that we find a design that does not involve
> pg_dump needing to dump out the extension contents, though: that seems
> to me to be missing the point of having extensions in the first place.
I was just trying to explain where I'm coming from, I'm not wed
On Mon, Jan 23, 2012 at 9:31 AM, Simon Riggs wrote:
> Test duration is important for tests that don't relate to pure
> contention reduction, which is every patch apart from XLogInsert.
Yes, I know. I already said that I was working on more tests to
address other use cases.
> I'm very happy to s
On Tue, Jan 3, 2012 at 2:49 PM, Pavel Stehule wrote:
> jup, we can continue in enhancing step by step.
>
> I change a patch and now ALTER TABLE, ALTER INDEX, ALTER SEQUENCE and
> ALTER VIEW has IF EXISTS clause
ALTER FOREIGN TABLE should be parallel as well, I think.
--
Robert Haas
EnterpriseDB
On Mon, Jan 23, 2012 at 10:04 AM, Dimitri Fontaine
wrote:
> And then basebackup and pg_upgrade would just work, and for dump and
> restore we still need to find something not violating the POLA.
>
> I think that would mean offering a backend function that list all files
> from a given extension an
Robert Haas writes:
> Hmm. But CREATE EXTENSION / ALTER EXTENSION doesn't seem right,
> because the files in the directory correspond to *available*
> extensions, not already-created ones. We need some way of dumping and
I would have limited the dump query to only known installed extensions,
ri
On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer wrote:
> * Robert Haas:
>>> In this particular case, I knew that the change was coming and could
>>> push updated Java and Perl client libraries well before the server-side
>>> change hit our internal repository, but I really don't want to have to
>>
On Mon, Jan 23, 2012 at 10:26 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Hmm. But CREATE EXTENSION / ALTER EXTENSION doesn't seem right,
>> because the files in the directory correspond to *available*
>> extensions, not already-created ones. We need some way of dumping and
>
> I would
On Mon, Jan 23, 2012 at 3:09 PM, Robert Haas wrote:
> I'm working on it.
Good, thanks for the update.
>> The remaining patch you tested was withdrawn and not submitted to the CF.
>
> Oh. Which one was that? I thought all of these were in play.
freelist_ok was a prototype for testing/discuss
Robert Haas writes:
> Hmm, I don't think I like that design. I think we should view this as
> a way to embed the SQL and control files needed by the extension in
> the server, rather than a separate thing called an inline extension.
> If pg_dump is going to dump those files, it ought to dump them
On Mon, Jan 23, 2012 at 10:35 AM, Simon Riggs wrote:
> freelist_ok was a prototype for testing/discussion, which contained an
> arguable heuristic. I guess that means its also "in play", but I
> wasn't thinking we'd be able to assemble clear evidence for 9.2.
OK, that one is still in the test run
On Mon, Jan 23, 2012 at 10:46 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Hmm, I don't think I like that design. I think we should view this as
>> a way to embed the SQL and control files needed by the extension in
>> the server, rather than a separate thing called an inline extension.
On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen wrote:
> On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen
> wrote:
>> * introduced a new GUC variable array_output copying the current
>> bytea_output type, with values "full" (old value) and
>> "smallfixed" (new default)
>> * added documentation for
On Mon, Jan 23, 2012 at 01:21:20AM +0400, Alexander Korotkov wrote:
> Updated patch is attached. I've updated comment
> of mcelem_array_contained_selec with more detailed description of
> probability distribution assumption. Also, I found that "rest" behavious
> should be better described by Poisso
Robert Haas writes:
> On Mon, Jan 23, 2012 at 12:12 AM, Tom Lane wrote:
>>> The expensive part of what
>>> we do while holding BufFreelistLock is, I think, iterating through
>>> buffers taking and releasing a spinlock on each one (!).
>> Yeah ... spinlocks that, by definition, will be unconteste
On Mon, Jan 23, 2012 at 11:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 23, 2012 at 12:12 AM, Tom Lane wrote:
The expensive part of what
we do while holding BufFreelistLock is, I think, iterating through
buffers taking and releasing a spinlock on each one (!).
>
>>>
On Mon, Jan 23, 2012 at 10:34:12AM -0500, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer wrote:
> > * Robert Haas:
> >>> In this particular case, I knew that the change was coming and could
> >>> push updated Java and Perl client libraries well before the server-side
> >>> ch
Robert Haas writes:
>> Ok, but then, what about .so files? Wouldn't it make sense to be able
>> to ship also the executable modules needed, and if not, why not?
>
> Sure, that would be as useful as any other part of this feature. We'd
> have to think carefully about how to make it secure, though
Robert Haas writes:
> On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen wrote:
>> Now that I think about it, same applies to bytea_output?
> Probably so. But I think we need not introduce quite so many new
> threads on this patch. This is, I think, at least thread #4, and
> that's making the discus
On Mon, Jan 23, 2012 at 5:34 PM, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer wrote:
>> * Robert Haas:
In this particular case, I knew that the change was coming and could
push updated Java and Perl client libraries well before the server-side
change hit our
On Mon, Jan 23, 2012 at 11:20:52AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen wrote:
> >> Now that I think about it, same applies to bytea_output?
>
> > Probably so. But I think we need not introduce quite so many new
> > threads on this patch.
On Mon, Jan 23, 2012 at 7:58 PM, Noah Misch wrote:
> > + /* Take care about events with low probabilities. */
> > + if (rest > DEFAULT_CONTAIN_SEL)
> > + {
>
> Why the change from "rest > 0" to this in the latest version?
>
Ealier addition of "rest" distribution require O(m) time. Now
On Fri, Jan 13, 2012 at 2:29 PM, Christopher Browne wrote:
> On Fri, Jan 13, 2012 at 3:14 PM, Frederico wrote:
>> Hi folks.
>>
>> Is there any restriction in create and start threads inside Postgres?
>>
>> I'm trying to develop a multithread planner, and some times is raised a
>> exception of ac
Marko Kreen writes:
> [ bytea_output doesn't need to be GUC_REPORT because format is autodetectable
> ]
Fair enough. Anyway we're really about two years too late to revisit that.
> Btw, it does not seems that per-request metainfo change requires
> "major version". It just client can send extr
Excerpts from Noah Misch's message of vie ene 20 22:33:30 -0300 2012:
> On Fri, Jan 20, 2012 at 07:03:22PM -0500, Jaime Casanova wrote:
> > On Wed, Jan 18, 2012 at 7:01 PM, Noah Misch wrote:
> > > On Wed, Jan 18, 2012 at 09:46:20AM -0500, Jaime Casanova wrote:
> > >>
> > >> ignoring all non-leaf
On Jan 23, 2012, at 2:49 PM, Tom Lane wrote:
> Marko Kreen writes:
>> [ bytea_output doesn't need to be GUC_REPORT because format is
>> autodetectable ]
>
> Fair enough. Anyway we're really about two years too late to revisit that.
>
>> Btw, it does not seems that per-request metainfo change
On sön, 2012-01-22 at 11:43 -0500, Andrew Dunstan wrote:
> Actually, given recent discussion I think that test should just be
> removed from json.c. We don't actually have any test that the code
> point is valid (e.g. that it doesn't refer to an unallocated code
> point). We don't do that elsewher
On Wed, Jan 18, 2012 at 9:19 AM, Jim Mlodgenski wrote:
> On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
> wrote:
>> On 18.01.2012 07:49, Fujii Masao wrote:
>>>
>>> On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenski wrote:
I have a need to send banner messages to a psql client that I c
On Mon, Jan 23, 2012 at 11:15 AM, Noah Misch wrote:
> As I said upthread, and you appeared to agree, the protocol is independent of
> individual data type send/recv formats. Even if we were already adding
> protocol v4 to PostgreSQL 9.2, having array_send() change its behavior in
> response to th
On Mon, Jan 23, 2012 at 2:00 PM, A.M. wrote:
> One simple way clients could detect the binary encoding at startup would be
> to pass known test parameters and match against the returned values. If the
> client cannot match the response, then it should choose the text
> representation.
>
> Alter
Hello Peter
I checked code, and I don't think so this is good.
A design of optional NULL is going to inconsistent syntax.
RETURN (OLD, NEW, NULL, /* nothing */) is not consistent
But my main argument is not intuitive behave of BEFORE triggers after
this change.
When somebody write BEFORE trig
On Mon, Jan 23, 2012 at 3:06 PM, Robert Haas wrote:
> Not being responsible from the maintenance of any PostgreSQL drivers
> whatsoever, I don't have a strong feeling about which of these is the
> case, and I'd like us to hear from the people who do.
I'm just gonna come right out and say that GUC
On Mon, Jan 23, 2012 at 11:06 PM, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 11:15 AM, Noah Misch wrote:
>> As I said upthread, and you appeared to agree, the protocol is independent of
>> individual data type send/recv formats. Even if we were already adding
>> protocol v4 to PostgreSQL 9.2,
On Jan 23, 2012, at 4:45 PM, Merlin Moncure wrote:
> On Mon, Jan 23, 2012 at 2:00 PM, A.M. wrote:
>> One simple way clients could detect the binary encoding at startup would be
>> to pass known test parameters and match against the returned values. If the
>> client cannot match the response, t
On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan wrote:
> Here's an update that adds row_to_json, plus a bit more cleanup.
why not call all these functions 'to_json' and overload them?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 01/23/2012 05:21 PM, Merlin Moncure wrote:
On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan wrote:
Here's an update that adds row_to_json, plus a bit more cleanup.
why not call all these functions 'to_json' and overload them?
I don't honestly feel that advances clarity much. And we mi
2012/1/23 Merlin Moncure :
> On Sun, Jan 15, 2012 at 10:08 AM, Andrew Dunstan wrote:
>> Here's an update that adds row_to_json, plus a bit more cleanup.
>
> why not call all these functions 'to_json' and overload them?
-1
older proposal is more consistent with xml functions
Pavel
>
> merlin
-
On Mon, Jan 23, 2012 at 4:12 PM, A.M. wrote:
> On Jan 23, 2012, at 4:45 PM, Merlin Moncure wrote:
>> Prefer the version. But why send this over and over with each bind?
>> Wouldn't you negotiate that when connecting? Most likely, optionally,
>> doing as much as you can from the server version? P
On Mon, Jan 23, 2012 at 04:56:24PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of vie ene 20 22:33:30 -0300 2012:
> > pgstattuple() figures the free_percent by adding up all space available to
> > hold tuples and dividing that by the simple size of the relation. Non-leaf
> >
On Mon, Jan 23, 2012 at 3:49 PM, Robert Haas wrote:
>> The other patches have clearer and specific roles without heuristics
>> (mostly), so are at least viable for 9.2, though still requiring
>> agreement.
>
> I think we must also drop removebufmgrfreelist-v1 from consideration,
...
I think you
On Mon, Jan 23, 2012 at 8:17 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Ok, but then, what about .so files? Wouldn't it make sense to be able
>>> to ship also the executable modules needed, and if not, why not?
>
> Now you can dump/restore any extension fully, and we can even ship any
On Mon, Jan 23, 2012 at 7:52 PM, Simon Riggs wrote:
> On Mon, Jan 23, 2012 at 3:49 PM, Robert Haas wrote:
>
>>> The other patches have clearer and specific roles without heuristics
>>> (mostly), so are at least viable for 9.2, though still requiring
>>> agreement.
>>
>> I think we must also drop
On 19/01/12 20:28, Hitoshi Harada wrote:
>> (Now it occurred to me that forgetting the #include parse_func.h might
>> hit this breakage..., so I'll fix it here and continue to test, but if
>> you'll fix it yourself, let me know)
>
> I fixed it here and it now works with my environment.
Well spott
On 22 January 2012 05:30, Peter Geoghegan wrote:
> The syntax for constants is sufficiently simple that I think that a
> good set of regression tests should make this entirely practicable,
> covering all permutations of relevant factors affecting how the
> implementation should act, including for
Robert Haas wrote:
On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes wrote:
I'm finding the backend_writes column pretty unfortunate. The only
use I know of for it is to determine if the bgwriter is lagging
behind. Yet it doesn't serve even this purpose because it lumps
together the backend writ
Benedikt Grundmann wrote:
What I think is missing is a clear way to know if you are vacuuming
(and analyzing) enough, and how much you are paying for that.
Any good way to measure if you're vacuuming a particular table enough
needs to note how much free space is in that table and its inde
On Sat, Jan 21, 2012 at 6:12 PM, Jim Nasby wrote:
> On Jan 10, 2012, at 3:07 AM, Simon Riggs wrote:
>> I think we could add an option to check the checksum immediately after
>> we pin a block for the first time but it would be very expensive and
>> sounds like we're re-inventing hardware or OS fea
On Mon, Jan 23, 2012 at 3:21 AM, Benedikt Grundmann
wrote:
> On 19/01/12 17:39, Greg Smith wrote:
>> On 1/19/12 1:10 PM, Robert Haas wrote:
>> >I have to say that I find that intensely counterintuitive. The
>> >current settings are not entirely easy to tune correctly, but at least
>> >they're eas
> ** pgbench, permanent tables, scale factor 100, 300 s **
> 1 group-commit-2012-01-21 614.425851 -10.4%
> 8 group-commit-2012-01-21 4705.129896 +6.3%
> 16 group-commit-2012-01-21 7962.131701 +2.0%
> 24 group-commit-2012-01-21 13074.939290 -1.5%
> 32 group-commit-2012-01-21 12458.962510 +4.5%
> 80
On 24 January 2012 06:26, Tatsuo Ishii wrote:
>> ** pgbench, permanent tables, scale factor 100, 300 s **
>> 1 group-commit-2012-01-21 614.425851 -10.4%
>> 8 group-commit-2012-01-21 4705.129896 +6.3%
>> 16 group-commit-2012-01-21 7962.131701 +2.0%
>> 24 group-commit-2012-01-21 13074.939290 -1.5%
>
* Robert Treat:
> Would it be unfair to assert that people who want checksums but aren't
> willing to pay the cost of running a filesystem that provides
> checksums aren't going to be willing to make the cost/benefit trade
> off that will be asked for? Yes, it is unfair of course, but it's
> inter
89 matches
Mail list logo
