James Sewell writes:
> My question is in a rollback scenario is it possible to get PSQL to return
> a non 0 exit status?
Maybe you could use -c instead of -f?
$ psql -c 'select 1; select 1/0' regression
ERROR: division by zero
$ echo $?
1
You won't need explicit BEGIN/END because this is alrea
Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit :
> 2013/9/10 Ronan Dunklau :
> > For row-level triggers, it seems more complicated. From what I understand,
> > OLD/NEW tuples are fetched from the heap using their ctid (except for
> > BEFORE INSERT triggers). How could this be adapted for
On Thu, Oct 10, 2013 at 5:35 AM, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 8:20 PM, Bruce Momjian wrote:
>> I am not sure that having that external to the backend really makes
>> sense because I am concerned people will not use it. We can certainly
>> add it to change our defaults, of cour
On Thu, Oct 10, 2013 at 5:02 AM, Bruce Momjian wrote:
> On Wed, Oct 9, 2013 at 07:33:46PM -0700, Peter Geoghegan wrote:
>> I hear a lot of complaints about "the first 15 minutes experience" of
>> Postgres. It's easy to scoff at this kind of thing, but I think we
>> could do a lot better there, an
On Thu, Oct 10, 2013 at 2:04 AM, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 4:40 PM, Bruce Momjian wrote:
>>> Well, if a person does not use vacuum_work_mem, then the cost to that
>>> person is low. If they do, the benefits could be immense. At the
>>> Heroku office, I've had people wonder w
On Wed, Oct 9, 2013 at 11:58 PM, Robert Haas wrote:
> On Sat, Sep 14, 2013 at 3:03 AM, Amit Kapila wrote:
>>>On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
> On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
> > On 2013-07-08
On Tue, Oct 8, 2013 at 9:22 PM, Heikki Linnakangas
wrote:
>
>>
> Yeah, I definitely think we should work on the pg_rewind approach instead
> of this patch. It's a lot more flexible. The performance hit of WAL-logging
> hint bit updates is the price you have to pay, but a lot of people were OK
> wi
On Thu, Oct 10, 2013 at 3:17 AM, Gibheer wrote:
> On Mon, 7 Oct 2013 11:39:55 +0530
> Amit Kapila wrote:
>> Robert Haas wrote:
>> On Mon, Aug 5, 2013 at 2:04 AM, Andres Freund
>> wrote:
>> >>> Hmm. It seems like this match is making MaxConnections no longer
>> >>> mean the maximum number of con
Hello
2013/10/10 James Sewell
> Hello,
>
> I am using PSQL to run SQL from a file with the -f flag as follows:
>
> BEGIN
> SQL
> SQL
> ...
> END
>
> This gives me rollback on error and a nicer output than -1. This works
> fine.
>
> My question is in a rollback scenario is it possible to get PSQ
On Wed, Oct 9, 2013 at 7:22 PM, Andrew Dunstan wrote:
>
> On 10/09/2013 09:22 AM, Amit Kapila wrote:
>>
>> On Wed, Oct 9, 2013 at 9:15 AM, Amit Kapila
>> wrote:
>>>
>>> On Tue, Oct 8, 2013 at 6:03 PM, Andrew Dunstan
>>> wrote:
On 10/07/2013 11:34 PM, Amit Kapila wrote:
>
> On T
On Wed, Oct 9, 2013 at 8:20 PM, Bruce Momjian wrote:
> I am not sure that having that external to the backend really makes
> sense because I am concerned people will not use it. We can certainly
> add it to change our defaults, of course. Also consider many installs
> are automated.
Sure.
I wa
On Wed, Oct 9, 2013 at 08:15:44PM -0700, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 8:02 PM, Bruce Momjian wrote:
> > I think the simplest solution would be to have a parameter to initdb
> > which specifies how much memory you want to use, and set a new variable
> > available_mem from that,
On Wed, Oct 9, 2013 at 8:13 PM, Bruce Momjian wrote:
> My option is better, not perfect --- I don't know how many times I can
> say something again and again. Fortunately there are enough people who
> understand that on the lists.
+1 from me on the sentiment: the perfect cannot be allowed to be
On Wed, Oct 9, 2013 at 8:02 PM, Bruce Momjian wrote:
> I think the simplest solution would be to have a parameter to initdb
> which specifies how much memory you want to use, and set a new variable
> available_mem from that, and have things auto-tune based on that value
> in the backend.
Have you
On Wed, Oct 9, 2013 at 09:34:16PM -0400, Robert Haas wrote:
> On Wed, Oct 9, 2013 at 9:11 PM, Bruce Momjian wrote:
> > On Wed, Oct 9, 2013 at 08:55:33PM -0400, Robert Haas wrote:
> >> On Wed, Oct 9, 2013 at 4:10 PM, Bruce Momjian wrote:
> >> > I disagree. I think we can get a forumla that is c
On Wed, Oct 9, 2013 at 07:33:46PM -0700, Peter Geoghegan wrote:
> I hear a lot of complaints about "the first 15 minutes experience" of
> Postgres. It's easy to scoff at this kind of thing, but I think we
> could do a lot better there, and at no real cost - the major blocker
> to doing something l
On Wed, Oct 9, 2013 at 09:34:16PM -0400, Robert Haas wrote:
> On a more pedestrian note, when I try this patch with shared_buffers =
> 8GB, the postmaster won't start. It dies with:
>
> FATAL: -20203 is outside the valid range for parameter "work_mem" (-1
> .. 2147483647)
Fixed with the attach
On Wed, Oct 9, 2013 at 7:11 PM, Stephen Frost wrote:
> There is definitely something to be said for simplicity and just up'ing
> the default would have a more dramatic impact with a setting like
> work_mem than it would with shared_buffers, imv.
Simplicity for us or for our users? Yes, shared_buf
* Bruce Momjian (br...@momjian.us) wrote:
> For servers that are not dedicated, a fixed value can easily be too
> large, and for a larger server, the value can easily be too small. Not
> sure how you can argue that a fixed value could be better.
There is definitely something to be said for simpl
On Wed, Oct 9, 2013 at 9:11 PM, Bruce Momjian wrote:
> On Wed, Oct 9, 2013 at 08:55:33PM -0400, Robert Haas wrote:
>> On Wed, Oct 9, 2013 at 4:10 PM, Bruce Momjian wrote:
>> > I disagree. I think we can get a forumla that is certainly better than
>> > a fixed value. I think the examples I have
On Wed, Oct 9, 2013 at 5:37 PM, Robert Haas wrote:
>> * Reordering of value locks generally. I still need to ensure this
>> will behave reasonably at higher isolation levels (i.e. they'll get a
>> serialization failure). I think that Robert accepts that this isn't
>> inconsistent with read committ
On Wed, Oct 9, 2013 at 08:55:33PM -0400, Robert Haas wrote:
> On Wed, Oct 9, 2013 at 4:10 PM, Bruce Momjian wrote:
> > I disagree. I think we can get a forumla that is certainly better than
> > a fixed value. I think the examples I have shown do have better value
> > than a default fixed value.
On Wed, Oct 9, 2013 at 4:10 PM, Bruce Momjian wrote:
> I disagree. I think we can get a forumla that is certainly better than
> a fixed value. I think the examples I have shown do have better value
> than a default fixed value. I am open to whatever forumula people think
> is best, but I can't
On 10/09/2013 08:39 PM, Robert Haas wrote:
On Wed, Oct 9, 2013 at 5:43 PM, Andrew Dunstan wrote:
On 10/09/2013 03:25 PM, Robert Haas wrote:
Therefore, a user who wants the opposite of the default behavior -
namely, unquoted empty strings as empty strings and quoted empty
strings as nulls - sh
On Wed, Oct 9, 2013 at 5:43 PM, Andrew Dunstan wrote:
> On 10/09/2013 03:25 PM, Robert Haas wrote:
>> Therefore, a user who wants the opposite of the default behavior -
>> namely, unquoted empty strings as empty strings and quoted empty
>> strings as nulls - should specify both FORCE NULL and FORC
On Wed, Oct 9, 2013 at 4:11 PM, Peter Geoghegan wrote:
> * The lock starvation hazards around going from value locking to row
> locking, and retrying if it doesn't work out (i.e. if the row and its
> descendant rows cannot be locked without what would ordinarily
> necessitate using EvalPlanQual())
On Wed, Oct 9, 2013 at 4:40 PM, Bruce Momjian wrote:
>> Well, if a person does not use vacuum_work_mem, then the cost to that
>> person is low. If they do, the benefits could be immense. At the
>> Heroku office, I've had people wonder why creating an index took what
>> seemed like way too long. I
On Wed, Oct 9, 2013 at 03:57:14PM -0700, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 3:31 PM, Bruce Momjian wrote:
> > Splitting out vacuum_work_mem from maintenance_work_mem is a separate
> > issue. I assume they were combined because the memory used for vacuum
> > index scans is similar to
Folks,
When you update a patch, please make sure to let your reviewer(s) know
you have in addition to putting it in the Commitfest application.
This will help ensure that your patch moves along its track to a
satisfactory outcome for all this Commitfest.
Cheers,
David.
--
David Fetter http://fe
On Wed, Oct 9, 2013 at 3:31 PM, Bruce Momjian wrote:
> Splitting out vacuum_work_mem from maintenance_work_mem is a separate
> issue. I assume they were combined because the memory used for vacuum
> index scans is similar to creating an index.
Is it similar? Doesn't maintenace_work_mem just bou
Marking this patch as "returned with feedback", I will not be able to
work on that by the 15th of October. It would have been great to get
the infrastructure patches 0002 and 0003 committed to minimize the
work on the core patch, but well it is not the case.
I am attaching as well a patch fixing s
On Wed, Oct 9, 2013 at 03:04:24PM -0700, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 2:15 PM, Bruce Momjian wrote:
> > I did like Josh's idea about using autovacuum_max_workers for
> > maintenance_work_mem, though I used the shared_buffers/4 calculation.
>
> I don't like that idea myself, be
Hello,
I am using PSQL to run SQL from a file with the -f flag as follows:
BEGIN
SQL
SQL
...
END
This gives me rollback on error and a nicer output than -1. This works fine.
My question is in a rollback scenario is it possible to get PSQL to return
a non 0 exit status?
Cheers,a
James
--
J
On Wed, Oct 9, 2013 at 2:15 PM, Bruce Momjian wrote:
> I did like Josh's idea about using autovacuum_max_workers for
> maintenance_work_mem, though I used the shared_buffers/4 calculation.
I don't like that idea myself, because I wouldn't like to link
maintenance_work_mem to autovacuum_max_worker
On Mon, 7 Oct 2013 11:39:55 +0530
Amit Kapila wrote:
> Robert Haas wrote:
> On Mon, Aug 5, 2013 at 2:04 AM, Andres Freund
> wrote:
> >>> Hmm. It seems like this match is making MaxConnections no longer
> >>> mean the maximum number of connections, but rather the maximum
> >>> number of non-repli
On 10/09/2013 03:25 PM, Robert Haas wrote:
Therefore, a user who wants the opposite of the default behavior -
namely, unquoted empty strings as empty strings and quoted empty
strings as nulls - should specify both FORCE NULL and FORCE NOT NULL.
Is there a real world example of this case? How
On Wed, Oct 9, 2013 at 02:11:47PM -0700, Josh Berkus wrote:
> On 10/09/2013 01:37 PM, Peter Geoghegan wrote:
> > If Heroku could increase maintenace_work_mem without having it affect
> > the amount of memory used by autovacuum workers, I'm fairly confident
> > that our setting would be higher. Sur
On Wed, Oct 9, 2013 at 09:52:03AM -0700, Josh Berkus wrote:
> On 10/09/2013 09:30 AM, Stephen Frost wrote:
> >>> I went with shared_buffers because unlike the others, it is a fixed
> >>> > > allocation quantity, while the other are much more variable and harder
> >>> > > to set. I figured we coul
On 10/09/2013 01:37 PM, Peter Geoghegan wrote:
> If Heroku could increase maintenace_work_mem without having it affect
> the amount of memory used by autovacuum workers, I'm fairly confident
> that our setting would be higher. Sure, you can just increase it as
> you need to, but you have to know ab
On Wed, Oct 9, 2013 at 7:30 AM, Bruce Momjian wrote:
> Josh Berkus suggested here that work_mem and maintenance_work_mem could
> be auto-tuned like effective_cache_size:
Have you ever thought that the role of maintenance_work_mem was a bit
muddled? It recently occurred to me that it might be a go
On Wed, Oct 9, 2013 at 11:24 AM, Robert Haas wrote:
> This patch is still marked as "Needs Review" in the CommitFest
> application. There's no reviewer, but in fact Andres and I both spent
> quite a lot of time providing design feedback (probably more than I
> spent on any other CommitFest patch)
On Wed, Oct 9, 2013 at 02:34:19PM -0400, Robert Haas wrote:
> On Wed, Oct 9, 2013 at 2:28 PM, Bruce Momjian wrote:
> > On Wed, Oct 9, 2013 at 01:49:23PM -0400, Robert Haas wrote:
> >> > Having really bad defaults so everyone knows they are bad really isn't
> >> > user-friendly because the only p
Dne 17. 9. 2013 17:01 "Andres Freund" napsal(a):
>
> On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
> > On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu
wrote:
> > > How about adding new system view with new function which returns
> > > a single pg_controldata value in text type, and using a c
> What happens if someone changes the record on the foreign side between when
> we've read it and we do the UPDATE?
>
Concurrency control is job of FDW driver. It has to coordinate access to
the records to be fetched for update / delete.
In fact, postgres_fdw add "FOR UPDATE" to avoid concurrent up
On Wed, Oct 9, 2013 at 9:52 AM, Andrew Dunstan wrote:
> I really don't know what you're saying here.
>
> Here is the situation we have today (assuming the default null marker of
> empty-string):
>
> default: empty-string -> null, quoted-empty-string ->
> emptystring
> with force_not_
On 2013-10-09 10:02:12 -0700, Joshua D. Drake wrote:
>
> On 10/09/2013 07:58 AM, Bruce Momjian wrote:
>
> >>But it still is an independent parameter. I am just changing the default.
> >>
> >>>maintenance_work_mem can depend on work_mem ~ work_mem * 1 *
> >>>max_connection / 4
> >>
> >>That is k
On Thu, Sep 12, 2013 at 11:21 PM, Peter Eisentraut wrote:
> On Tue, 2013-09-03 at 22:41 -0400, Peter Eisentraut wrote:
>> The maintainer-check target never really caught on, I think. Most
>> people don't run it, and that in turn annoys those who do. Also, it
>> doesn't provide much functionality
On Tue, Sep 3, 2013 at 8:35 AM, Antonin Houska wrote:
> On 07/24/2013 09:20 AM, Antonin Houska wrote:
>> Hello,
>> the purpose of this patch is to limit impact of pg_backup on running
>> server.
>
> Attached is a new version. Server-side implementation this time.
>
> Antonin Houska (Tony)
There s
On Tue, Oct 1, 2013 at 9:33 PM, Peter Eisentraut wrote:
> On Sun, 2013-09-15 at 18:27 +0200, Marko Tiikkaja wrote:
>> I think the reasoning behind this patch is sound. However, I would like
>> to raise a couple of small questions:
>>
>>1) Is there a reason for the fmt string not being const c
On Mon, Sep 30, 2013 at 6:44 PM, Andres Freund wrote:
> The series from friday was a bit too buggy - obviously I was too
> tired. So here's a new one:
>
> * fix pg_recvlogical makefile (Thanks Steve)
> * fix two commits not compiling properly without later changes (Thanks Kevin)
> * keep track of
On Tue, Sep 17, 2013 at 11:43 AM, Robert Haas wrote:
> On Tue, Sep 17, 2013 at 10:59 AM, Andres Freund
> wrote:
>> On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
>>> On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu wrote:
>>> > How about adding new system view with new function which returns
Soroosh Sardari wrote:
> I'm developing a new type for character string, like varchar. I
> wrote operators for btree and so forth.
>
> I wonder how pattern matching operators using btree index,
> because btree operator class ony knows about >, >=, <=, and =
> operators, but operators for pattern
On Wed, Oct 9, 2013 at 2:28 PM, Bruce Momjian wrote:
> On Wed, Oct 9, 2013 at 01:49:23PM -0400, Robert Haas wrote:
>> > Having really bad defaults so everyone knows they are bad really isn't
>> > user-friendly because the only people who know they are really bad are
>> > the people who are tuning
On Sat, Sep 14, 2013 at 3:03 AM, Amit Kapila wrote:
>>On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
>>>On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
> On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
> > +This utilit
On Mon, Sep 30, 2013 at 9:11 PM, Peter Geoghegan wrote:
> On Mon, Sep 30, 2013 at 3:45 PM, Peter Geoghegan wrote:
>> If you think it's a bit odd that we lock every value while the user
>> essentially has one constraint in mind when writing their DML,
>> consider:
>
> I should add to that list:
>
On Wed, Oct 9, 2013 at 01:49:23PM -0400, Robert Haas wrote:
> > Having really bad defaults so everyone knows they are bad really isn't
> > user-friendly because the only people who know they are really bad are
> > the people who are tuning them already. Again, we need to think of the
> > typical
On 10/8/13 5:55 AM, shailesh singh wrote:
> HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
> ERROR: could not access status of transaction 449971277
> DETAIL: could not open file "pg_clog/01AD": No such file or directory
Unless I'm mistaken, that missing CLOG f
On Tue, Sep 24, 2013 at 10:40 PM, Peter Eisentraut wrote:
> On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
>> Hmm not sure i understand this argument either: this patch doesn't
>> allow disabling a primary key. It only supports FKs and CHECK
>> constraints explicitly.
>
> Well, as soon as
On Tue, Sep 24, 2013 at 9:07 AM, Stas Kelvich wrote:
> Hello
>
> There is new version of patch. I have separated ordering operators to
> different patch
> (https://commitfest.postgresql.org/action/patch_view?id=1243), fixed
> formatting issues and implemented backward compatibility with old-sty
On Wed, Oct 9, 2013 at 12:57 PM, Pavel Stehule wrote:
> here is a patch for RAISE WHEN clause
This is in effect a whole new patch by a different author. Please
submit it to the next CommitFest; I'm marking the entry for
"Assertions in PL/PgSQL" as "Returned with Feedback".
--
Robert Haas
Enter
Of the 83 patches in this CommitFest, there are currently 35 that are
marked as needing review, 23 that are waiting on author, 7 that are
ready for committer, 11 that are committed, 5 that are returned with
feedback, and 2 that are rejected. Since we're now supposedly in the
last week of this mont
On 10/6/13 3:33 PM, Kohei KaiGai wrote:
2013/9/10 Ronan Dunklau :
For row-level triggers, it seems more complicated. From what I understand,
OLD/NEW tuples are fetched from the heap using their ctid (except for BEFORE
INSERT triggers). How could this be adapted for foreign tables ?
It seems to
On 10/09/2013 01:25 PM, David Fetter wrote:
Idea:
NULL FOR (foo,bar,baz,blurf) AS '""', NULL FOR (quux,fleeg) AS ...,
What's the point of this? How is this superior to what is currently
proposed? Having arbitrary NULL markers for different fields will
significantly increase code complex
On Wed, Oct 9, 2013 at 1:44 PM, Bruce Momjian wrote:
> On Wed, Oct 9, 2013 at 01:34:21PM -0400, Robert Haas wrote:
>> And quite frankly I don't think I really believe the auto-tuning
>> formula has much chance of being right in the first place. It's
>> generally true that you're going to need to
On Wed, Oct 9, 2013 at 4:54 AM, Samrat Revagade
wrote:
> On Tue, Oct 8, 2013 at 3:16 PM, Andres Freund
> wrote:
>> On 2013-10-08 15:07:02 +0530, Pavan Deolasee wrote:
>> > On Tue, Oct 8, 2013 at 2:33 PM, Sawada Masahiko
>> > wrote:
>> >
>> > > On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao
>> > > w
On Wed, Oct 9, 2013 at 01:34:21PM -0400, Robert Haas wrote:
> And quite frankly I don't think I really believe the auto-tuning
> formula has much chance of being right in the first place. It's
> generally true that you're going to need to increase work_mem if you
> have more memory and decrease i
On Wed, Oct 9, 2013 at 10:30 AM, Bruce Momjian wrote:
> Josh Berkus suggested here that work_mem and maintenance_work_mem could
> be auto-tuned like effective_cache_size:
>
> http://www.postgresql.org/message-id/50eccf93.3060...@agliodbs.com
I think that this is unlikely to work out well.
On Wed, Oct 09, 2013 at 09:52:29AM -0400, Andrew Dunstan wrote:
>
> On 10/09/2013 09:22 AM, Amit Kapila wrote:
> >On Wed, Oct 9, 2013 at 9:15 AM, Amit Kapila wrote:
> >>On Tue, Oct 8, 2013 at 6:03 PM, Andrew Dunstan wrote:
> >>>On 10/07/2013 11:34 PM, Amit Kapila wrote:
> On Tue, Oct 8, 2013
On 10/09/2013 10:07 AM, Bruce Momjian wrote:
> We can have the discussion here or in another thread. I am thinking the
> right fix is to allocate larger shared_buffers, especially now that we
> don't require a larger System V shared memory segement. Basically, for
> 128MB of shared buffers, I fig
On Wed, Oct 9, 2013 at 12:41:53PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I think we should try to hit the existing defaults, which would mean we
> > would use this computation:
>
> For my 2c, I was hoping this would improve things for our users by
> raising th
On 10/09/2013 07:58 AM, Bruce Momjian wrote:
But it still is an independent parameter. I am just changing the default.
maintenance_work_mem can depend on work_mem ~ work_mem * 1 * max_connection / 4
That is kind of hard to do because we would have to figure out if the
old maintenance_work_
Hello
2013/9/24 Robert Haas
> On Mon, Sep 23, 2013 at 5:48 AM, Amit Khandekar
> wrote:
> >>> The assert levels sound a bit like a user might be confused by these
> >>> levels being present at both places: In the RAISE syntax itself, and
> the
> >>> assert GUC level. But I like the syntax. How
On Wed, Oct 9, 2013 at 12:25:49PM -0400, Bruce Momjian wrote:
> > I'm not saying don't do it, but I think we need to be quite
> > conservative about it. A reasonable default might be (shared_buffers
> > / (n * max_connections)) FSVO n, but I'm not sure what n should be.
> > Instinct says something
On Wed, Oct 09, 2013 at 12:30:22PM -0400, Stephen Frost wrote:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > 2013/10/9 Bruce Momjian
> > > I went with shared_buffers because unlike the others, it is a fixed
> > > allocation quantity, while the other are much more variable and harder
> > >
On 10/09/2013 09:30 AM, Stephen Frost wrote:
>>> I went with shared_buffers because unlike the others, it is a fixed
>>> > > allocation quantity, while the other are much more variable and harder
>>> > > to set. I figured we could keep our 25% estimate of shared_buffers and
>>> > > everything else
* Bruce Momjian (br...@momjian.us) wrote:
> I think we should try to hit the existing defaults, which would mean we
> would use this computation:
For my 2c, I was hoping this would improve things for our users by
raising the tiny 1M default work_mem, so I don't agree that we should
simply be comin
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2013/10/9 Bruce Momjian
> > I went with shared_buffers because unlike the others, it is a fixed
> > allocation quantity, while the other are much more variable and harder
> > to set. I figured we could keep our 25% estimate of shared_buffers and
On Wed, Oct 9, 2013 at 06:20:13PM +0200, Pavel Stehule wrote:
> On Wed, Oct 9, 2013 at 05:01:24PM +0200, Pavel Stehule wrote:
> > FYI, this auto-tuning is not for us, who understand the parameters
> and
> > how they interact, but for the 90% of our users who would benefit
On Wed, Oct 9, 2013 at 11:06:07AM -0400, Andrew Dunstan wrote:
>
> On 10/09/2013 10:45 AM, Bruce Momjian wrote:
> >On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote:
> >> Effectively, if every session uses one full work_mem, you end up with
> >> total work_mem usage equal to s
2013/10/9 Bruce Momjian
> On Wed, Oct 9, 2013 at 05:01:24PM +0200, Pavel Stehule wrote:
> > FYI, this auto-tuning is not for us, who understand the parameters
> and
> > how they interact, but for the 90% of our users who would benefit
> from
> > better defaults. It is true that ther
On 10/09/2013 11:23 AM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
I don't see at all that your suggested alternative has any advantages over
what's been written. If you can say "NULL FOR (foo) as '""' how will you
specify the null for some other column(s)? Are we going to have multiple
su
On Wed, Oct 9, 2013 at 05:01:24PM +0200, Pavel Stehule wrote:
> FYI, this auto-tuning is not for us, who understand the parameters and
> how they interact, but for the 90% of our users who would benefit from
> better defaults. It is true that there might now be cases where you
> w
Andrew Dunstan writes:
> I don't see at all that your suggested alternative has any advantages over
> what's been written. If you can say "NULL FOR (foo) as '""' how will you
> specify the null for some other column(s)? Are we going to have multiple
> such clauses? It looks like a real mess.
Basi
On 10/09/2013 10:45 AM, Bruce Momjian wrote:
On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote:
Effectively, if every session uses one full work_mem, you end up with
total work_mem usage equal to shared_buffers.
We can try a different algorithm to scale up work_mem,
2013/10/9 Bruce Momjian
> On Wed, Oct 9, 2013 at 10:45:52AM -0400, Bruce Momjian wrote:
> > On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote:
> > > Effectively, if every session uses one full work_mem, you end up
> with
> > > total work_mem usage equal to shared_buffers.
> >
On Wed, Oct 9, 2013 at 10:45:52AM -0400, Bruce Momjian wrote:
> On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote:
> > Effectively, if every session uses one full work_mem, you end up with
> > total work_mem usage equal to shared_buffers.
> >
> > We can try a different alg
On 2013-10-09 10:35:28 -0400, Bruce Momjian wrote:
> On Wed, Oct 9, 2013 at 04:32:44PM +0200, Andres Freund wrote:
> > On 2013-10-09 10:30:46 -0400, Bruce Momjian wrote:
> > > Josh Berkus suggested here that work_mem and maintenance_work_mem could
> > > be auto-tuned like effective_cache_size:
> >
On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote:
> Effectively, if every session uses one full work_mem, you end up with
> total work_mem usage equal to shared_buffers.
>
> We can try a different algorithm to scale up work_mem, but it seems wise
> to auto-scale it up
On Wed, Oct 9, 2013 at 04:38:01PM +0200, Andres Freund wrote:
> On 2013-10-09 10:35:28 -0400, Bruce Momjian wrote:
> > On Wed, Oct 9, 2013 at 04:32:44PM +0200, Andres Freund wrote:
> > > On 2013-10-09 10:30:46 -0400, Bruce Momjian wrote:
> > > > Josh Berkus suggested here that work_mem and mainte
2013/10/9 Bruce Momjian
> On Wed, Oct 9, 2013 at 04:32:44PM +0200, Andres Freund wrote:
> > On 2013-10-09 10:30:46 -0400, Bruce Momjian wrote:
> > > Josh Berkus suggested here that work_mem and maintenance_work_mem could
> > > be auto-tuned like effective_cache_size:
> > >
> > > http://www.p
On Wed, Oct 9, 2013 at 04:32:44PM +0200, Andres Freund wrote:
> On 2013-10-09 10:30:46 -0400, Bruce Momjian wrote:
> > Josh Berkus suggested here that work_mem and maintenance_work_mem could
> > be auto-tuned like effective_cache_size:
> >
> > http://www.postgresql.org/message-id/50eccf93.306
On 2013-10-09 10:30:46 -0400, Bruce Momjian wrote:
> Josh Berkus suggested here that work_mem and maintenance_work_mem could
> be auto-tuned like effective_cache_size:
>
> http://www.postgresql.org/message-id/50eccf93.3060...@agliodbs.com
>
> The attached patch implements this, closely matc
Josh Berkus suggested here that work_mem and maintenance_work_mem could
be auto-tuned like effective_cache_size:
http://www.postgresql.org/message-id/50eccf93.3060...@agliodbs.com
The attached patch implements this, closely matching the default values
for the default shared_buffers value:
2013/10/9 Pavel Stehule
> Hello
>
> I checked a conformance with ANSI SQL - and I didn't find any issue.
>
> I found so following error message is not too friendly (mainly because
> this functionality will be new)
>
> postgres=# select dense_rank(3,3,2) within group (order by num desc, odd)
> fro
Robert Haas writes:
> I think we were going to try to group the extensions into categories
> (debugging tools, demonstration code, data types, etc.) and maybe
> encourage packagers to put the debugging tools in the same OS package
> as the core server. But Tom was not supportive, and he was at th
On 10/09/2013 09:22 AM, Amit Kapila wrote:
On Wed, Oct 9, 2013 at 9:15 AM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 6:03 PM, Andrew Dunstan wrote:
On 10/07/2013 11:34 PM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan
wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
On Wed, Oct 9, 2013 at 9:15 AM, Amit Kapila wrote:
> On Tue, Oct 8, 2013 at 6:03 PM, Andrew Dunstan wrote:
>>
>> On 10/07/2013 11:34 PM, Amit Kapila wrote:
>>>
>>> On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan
>>> wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
>
>
>> A
On Wed, Oct 9, 2013 at 01:03:24AM -0400, Peter Eisentraut wrote:
> Where did this patch come from?
>
> I think part of that patch should be reverted, but I can't find the
> original submission for the rationale.
Sure, it is from here:
http://www.postgresql.org/message-id/e1vofi4-0005nz
On Wed, Oct 9, 2013 at 01:15:10PM +0900, Amit Langote wrote:
> Hi,
>
> In the release notes for 9.2.5,
>
> Should the following:
>
> "Fix rare GROUP BY query error caused by improperly processed date
> type modifiers (Tom Lane)"
>
> be:
>
> "Fix rare GROUP BY query error caused by improperly
On 09.10.2013 13:24, Soroosh Sardari wrote:
I'm developing a new type for character string, like varchar. I wrote
operators for btree and so forth.
I wonder how pattern matching operators using btree index, because btree
operator class ony knows about>,>=,<=, and = operators, but operators
for pa
1 - 100 of 102 matches
Mail list logo
