2013/10/21 Noah Misch
> On Mon, Oct 21, 2013 at 08:10:24PM +0200, Pavel Stehule wrote:
> > > On 10/20/2013 07:52 PM, Noah Misch wrote:
> > >> Anything we do here effectively provides wrappers around the existing
> > >> functions tailored toward the needs of libpq.
>
> To clarify the above stateme
On Mon, Oct 21, 2013 at 10:54 AM, Haribabu kommi
wrote:
> On 20 October 2013 12:06 Amit Kapila wrote:
>>On Tue, Oct 15, 2013 at 3:37 PM, Haribabu kommi
>>wrote:
>>> On 12 October 2013 11:30 Tom Lane wrote:
Haribabu kommi writes:
>>>
Another way to look at it is that we want to keep any
On Tue, Oct 22, 2013 at 9:22 AM, Fujii Masao wrote:
> On Tue, Oct 22, 2013 at 12:47 PM, Amit Kapila wrote:
>> On Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
>> wrote:
>>> (2013/10/19 14:58), Amit Kapila wrote:
On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
wrote:
>>
>>> In
>>> ac
On Tue, Oct 22, 2013 at 12:47 PM, Amit Kapila wrote:
> On Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
> wrote:
>> (2013/10/19 14:58), Amit Kapila wrote:
>>> On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
>>> wrote:
>>> In general, my thinking is that we should prefer compression to reduce
>
On Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
wrote:
> (2013/10/19 14:58), Amit Kapila wrote:
>> On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
>> wrote:
>> In general, my thinking is that we should prefer compression to reduce
>> IO (WAL volume), because reducing WAL volume has other benef
Hi
As a part of Course Project i have to implement this :
I have an 3 indexes on a relation t2(A,B,C) index1 , index2 ,index3
What i need is if i know the indexname (say index1) then is their any
programmatic way by which i can get the list of tuples which comes under
the index specified( i.e
On Tue, Oct 22, 2013 at 4:00 AM, Gavin Flower
wrote:
>> I have a proof of concept patch somewhere that does exactly this. I
>> used logarithmic bin widths. With 8 log10 bins you can tell the
>> fraction of queries running at each order of magnitude from less than
>> 1ms to more than 1000s. Or with
On 22/10/13 13:26, Ants Aasma wrote:
On Tue, Oct 22, 2013 at 1:09 AM, Alvaro Herrera
wrote:
Gavin Flower wrote:
One way it could be done, but even this would consume far too much
storage and processing power (hence totally impractical), would be
to 'simply' store a counter for each value foun
On 22/10/13 13:26, Ants Aasma wrote:
On Tue, Oct 22, 2013 at 1:09 AM, Alvaro Herrera
wrote:
Gavin Flower wrote:
One way it could be done, but even this would consume far too much
storage and processing power (hence totally impractical), would be
to 'simply' store a counter for each value foun
On Tue, Oct 22, 2013 at 1:09 AM, Alvaro Herrera
wrote:
> Gavin Flower wrote:
>
>> One way it could be done, but even this would consume far too much
>> storage and processing power (hence totally impractical), would be
>> to 'simply' store a counter for each value found and increment it
>> for eac
On Mon, Oct 21, 2013 at 4:29 PM, Tom Lane wrote:
> Hm. It's been a long time since college statistics, but doesn't the
> entire concept of standard deviation depend on the assumption that the
> underlying distribution is more-or-less normal (Gaussian)?
I don't see how. The standard deviation her
On 10/21/2013 07:29 PM, Tom Lane wrote:
Andrew Dunstan writes:
This is why I suggested the standard deviation, and why I find it would
be more useful than just min and max. A couple of outliers will set the
min and max to possibly extreme values but hardly perturb the standard
deviation over a
Andrew Dunstan writes:
> This is why I suggested the standard deviation, and why I find it would
> be more useful than just min and max. A couple of outliers will set the
> min and max to possibly extreme values but hardly perturb the standard
> deviation over a large number of observations.
Hm.
Robert Haas writes:
> Yeah, and I worry about min and max not being very usable - once they
> get pushed out to extreme values, there's nothing to drag them back
> toward normality except resetting the stats, and that's not something
> we want to encourage people to do frequently. Of course, avera
On 10/21/2013 04:43 PM, Peter Geoghegan wrote:
On Mon, Oct 21, 2013 at 1:36 PM, Robert Haas wrote:
Yeah, and I worry about min and max not being very usable - once they
get pushed out to extreme values, there's nothing to drag them back
toward normality except resetting the stats, and that's n
On 16/10/13 11:51, Mark Kirkwood wrote:
On 11/10/13 17:33, Jaime Casanova wrote:
also the name pgstattuple2, doesn't convince me... maybe you can use
pgstattuple() if you use a second argument (percentage of the sample)
to overload the function
+1, that seems much nicer.
Oh - and if you pro
Gavin Flower wrote:
> One way it could be done, but even this would consume far too much
> storage and processing power (hence totally impractical), would be
> to 'simply' store a counter for each value found and increment it
> for each occurence...
An histogram? Sounds like a huge lot of code c
Hi,
I would like to implement item from TODO marked as easy: "Add \i option
to bring in the specified file as a quoted literal". I understand intent
of this item, to be able to have parts of query written in separate
files (now it is impossible, because \i tries to execute content of file
as a sep
Tom Lane writes:
> I believe the reason GIST has compress/decompress functions is not for
> TOAST (they predate that, if memory serves), but to allow the on-disk
> representation of an index entry to be different from the data type's
> normal representation in other ways --- think lossy storage in
On 22/10/13 09:01, Tom Lane wrote:
Gavin Flower writes:
If we're going to extend pg_stat_statements, even more than min and max
I'd like to see the standard deviation in execution time.
How about the 'median', often a lot more useful than the 'arithmetic
mean' (which most people call the 'aver
> 9.3 has include_dir and postgresql.conf has this setted:
> """
> #include_dir = 'conf.d' # include files ending in '.conf' from
> # directory 'conf.d'
> """
>
> anything before this should be up to the packagers, no?
>
> or, do you mean something else?
Well, I was
On Mon, Oct 21, 2013 at 1:36 PM, Robert Haas wrote:
> Yeah, and I worry about min and max not being very usable - once they
> get pushed out to extreme values, there's nothing to drag them back
> toward normality except resetting the stats, and that's not something
> we want to encourage people to
On Mon, Oct 21, 2013 at 4:01 PM, Tom Lane wrote:
> Gavin Flower writes:
If we're going to extend pg_stat_statements, even more than min and max
I'd like to see the standard deviation in execution time.
>
>> How about the 'median', often a lot more useful than the 'arithmetic
>> mean' (w
On Mon, Oct 21, 2013 at 2:57 PM, Josh Berkus wrote:
> Jaime,
>
>>> And, as I said before, we need to do the GUC merger in the same release
>>> we introduce configuration directory (or after it).
>>>
>>
>> you mean the ALTER SYSTEM syntax? anyway, why that restriction?
>
> No, I'm referring to the
Jaime,
>> And, as I said before, we need to do the GUC merger in the same release
>> we introduce configuration directory (or after it).
>>
>
> you mean the ALTER SYSTEM syntax? anyway, why that restriction?
No, I'm referring to the proposal to have an automatically created and
included conf.d d
Gavin Flower writes:
>>> If we're going to extend pg_stat_statements, even more than min and max
>>> I'd like to see the standard deviation in execution time.
> How about the 'median', often a lot more useful than the 'arithmetic
> mean' (which most people call the 'average').
AFAIK, median is i
On 22/10/13 00:17, KONDO Mitsumasa wrote:
> (2013/10/18 22:21), Andrew Dunstan wrote:
>> If we're going to extend pg_stat_statements, even more than min and max
>> I'd like to see the standard deviation in execution time.
> OK. I do! I am making some other patches, please wait more!
>
> Regards,
>
On Mon, Oct 21, 2013 at 08:10:24PM +0200, Pavel Stehule wrote:
> > On 10/20/2013 07:52 PM, Noah Misch wrote:
> >> Anything we do here effectively provides wrappers around the existing
> >> functions tailored toward the needs of libpq.
To clarify the above statement: the existing lo* SQL functions
On Mon, Oct 21, 2013 at 11:53 AM, Josh Berkus wrote:
> On 10/18/2013 02:36 PM, Andres Freund wrote:
>>> > What will likely change first is Slony and Bucardo, who have a strong
>>> > interest in dumping triggers and queues.
>> But I don't understand what that has to do with recovery.conf and
>> bre
Hi,
On 2013-10-21 21:36:02 +0200, Andres Freund wrote:
> I think this approach would have lower maintenance overhead in
> comparison to the previous solution of Handling CommandIds because it's
> actually much simpler.
Btw, I think the new approach would allow for *easier* modifications
about fu
Alexander Korotkov writes:
> On Mon, Oct 21, 2013 at 11:06 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>> I guess it can't happen. Or is it possible that a toasted value that came
>> from disk will be passed to these functions, without detoasting them
>> somewhere along the way? Not
On 2013-10-21 14:50:54 -0400, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 2:27 PM, Andres Freund wrote:
> >> I think it's a complete no-go. Consider, e.g., the comment for
> >> MaxTupleAttributeNumber, which you've blithely falsified. Even if you
> >> update the comment and the value, I'm not i
On Mon, Oct 21, 2013 at 11:06 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 11.10.2013 17:39, Alexander Korotkov wrote:
>
>> On Fri, Oct 11, 2013 at 5:56 PM, Heikki Linnakangas> vmware.com
>>
>>> wrote:
>>>
>>
>> 2. I didn't understand this change:
>>>
>>> @@ -422,24 +439,14 @@
On Thu, Oct 10, 2013 at 3:57 PM, Heikki Linnakangas wrote:
> On 09.10.2013 02:04, Tomas Vondra wrote:
>
>> On 8.10.2013 21:59, Heikki Linnakangas wrote:
>>
>>> On 08.10.2013 17:47, Alexander Korotkov wrote:
>>>
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra wrote:
>
On 11.10.2013 17:39, Alexander Korotkov wrote:
On Fri, Oct 11, 2013 at 5:56 PM, Heikki Linnakangas
wrote:
2. I didn't understand this change:
@@ -422,24 +439,14 @@ g_cube_union(PG_FUNCTION_ARGS)
Datum
g_cube_compress(PG_FUNCTION_**ARGS)
{
- PG_RETURN_DATUM(PG_GETARG_**DATUM(0))
On Mon, Oct 21, 2013 at 2:48 PM, Peter Eisentraut wrote:
> On 10/21/13 9:18 AM, Andres Freund wrote:
>> I am not 100% sure, but what's the point of the CF if we're not actually
>> reviewing patches that wouldn't get review without it? So I guess it's
>> not starting the next one before we've finis
Josh Berkus writes:
> Either you're proposing a solution, supporting someone else's solution,
> or you're saying the problem isn't important. There is no fourth
> alternative.
Nonsense. Pointing out that a proposed solution isn't workable is not
saying that the problem isn't important. Or are
On Mon, Oct 21, 2013 at 2:27 PM, Andres Freund wrote:
>> I think it's a complete no-go. Consider, e.g., the comment for
>> MaxTupleAttributeNumber, which you've blithely falsified. Even if you
>> update the comment and the value, I'm not inspired by the idea of
>> subtracting 32 from that number
On 10/21/13 9:18 AM, Andres Freund wrote:
> I am not 100% sure, but what's the point of the CF if we're not actually
> reviewing patches that wouldn't get review without it? So I guess it's
> not starting the next one before we've finished - which we obviously
> haven't in this case - the last one.
On 22/10/13 02:56, Heikki Linnakangas wrote:
On 21.10.2013 16:15, Peter Eisentraut wrote:
On 10/21/13 1:31 AM, Andres Freund wrote:
The point of the CF is exactly that all
patches get at least one good round of review. Moving unreviewed
patches
to the next CF will let them just suffer the sam
On 2013-10-21 14:22:17 -0400, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 1:52 PM, Andres Freund wrote:
> >> > In my opinion, (4) is too ugly to consider. I think that if we start
> >> > playing games like this, we're opening up the doors to lots of subtle
> >> > bugs and future architectural pa
On 2013-10-18 20:50:58 +0200, Andres Freund wrote:
> How about modifying the selection to go from:
> * all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
> * index chosen by ALTER TABLE ... REPLICA IDENTITY USING indexname
> * [later, maybe] ALTER TABLE ... REPLICA IDENTITY (cola, colb)
Cu
On Mon, Oct 21, 2013 at 1:52 PM, Andres Freund wrote:
>> > In my opinion, (4) is too ugly to consider. I think that if we start
>> > playing games like this, we're opening up the doors to lots of subtle
>> > bugs and future architectural pain that will be with us for many, many
>> > years to come
Hello
2013/10/21 Andrew Dunstan
>
> On 10/20/2013 07:52 PM, Noah Misch wrote:
>
>> Consider this list of new functions in their place:
>>
>> lo_create(oid, bytea) RETURNS oid -- new LO with content (similar to
>> make_lo)
>> lo_get(oid) RETURNS bytea-- read entire LO (s
On Sat, Oct 5, 2013 at 7:54 PM, Alvaro Herrera wrote:
> MauMau escribió:
> > >>From: "Alvaro Herrera"
> > >>>Can you please send a fixup patch to what's already committed?
> > >>
> > >>OK, I'll send a patch against HEAD, which will be a few lines. Am I
> > >>understanding the meaning of "fixup p
2013-10-21 19:10 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
I hoped that reviewing 4 patches in this CF (UNNEST, Extension templates,
DISCARD SEQUENCES, and extended RETURNING syntax) gets my huge patch reviewed.
I'm still on the hook for parts of this one (and also for Pav
On Mon, Oct 21, 2013 at 5:27 AM, KONDO Mitsumasa
wrote:
> (2013/10/02 18:57), Michael Paquier wrote:
>>
>> wrote:
>>>
>>> Who is pgFoundery administrator or board member now? I would like to send
>>> e-mail
>>> them. At least, it does not have information and support page in
>>> pgFoundery homepa
Andres,
> I find it utterly ridiculous to accuse the people that *do* reviews of
> not doing anything. By doing code-level reviews reviewers teach authors
> and bystanders more about the code. Which actually can increase the
> number of review(ers) and even committers in the long run.
It would be
2013-10-21 18:25 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
I even provided a repo @github where it was broken up into pieces that can be
sanely reviewed.
You also gave the first person looking at the patch a hard time about
asking for it to be bro
On 10/21/2013 10:14 AM, Andres Freund wrote:
> Well, who are you going to get to review things that they consider
> simply bad ideas? I have no problem investing serious time in doing
> detailed reviews of patches I can see the point of, but reviews of stuff
> I think is pointless? Not really.
Tha
On 2013-10-21 10:19:22 -0700, Josh Berkus wrote:
> On 10/21/2013 10:14 AM, Andres Freund wrote:
> > Well, who are you going to get to review things that they consider
> > simply bad ideas? I have no problem investing serious time in doing
> > detailed reviews of patches I can see the point of, but
On 10/21/2013 06:56 AM, Heikki Linnakangas wrote:
> I feel guilty to complain, while not actually volunteering to be a
> commitfest manager myself, but I wish the commitfest manager would be
> more aggressive in nagging, pinging and threatening people to review
> stuff. If nothing else, always feel
On 2013-10-21 09:58:30 -0700, Josh Berkus wrote:
> Tom,
>
> >> If no-one really cares enough about a patch to review it, mark it
> >> as "rejected, because no-one but the patch author cares". Harsh,
> >> but that's effectively what pushing to the next commitfest means
> >> anyway.
> >
> > Well, t
Boszormenyi Zoltan escribió:
> I hoped that reviewing 4 patches in this CF (UNNEST, Extension templates,
> DISCARD SEQUENCES, and extended RETURNING syntax) gets my huge patch reviewed.
I'm still on the hook for parts of this one (and also for Pavel's date
constructors stuff). I won't touch the
Tom,
>> If no-one really cares enough about a patch to review it, mark it
>> as "rejected, because no-one but the patch author cares". Harsh,
>> but that's effectively what pushing to the next commitfest means
>> anyway.
>
> Well, that could be the problem, but it's also possible that no one
> co
On 10/18/2013 02:36 PM, Andres Freund wrote:
>> > What will likely change first is Slony and Bucardo, who have a strong
>> > interest in dumping triggers and queues.
> But I don't understand what that has to do with recovery.conf and
> breakage around it.
The simple thinking is this: if we announc
Nigel,
* Nigel Heron (nhe...@querymetrics.com) wrote:
> Hi, I've been using postgres for many years but never took the time to play
> with the code until now. As a learning experience i came up with this WIP
> patch to keep track of the # of bytes sent and received by the server over
> it's commun
* Magnus Hagander (mag...@hagander.net) wrote:
> +1. If changing at all, then maybe just "autovacuum_mem"? It's not
> like there's a different parameter to control a different kind of
> memory in autovac, is there?
+1 on that, for my 2c.
Thanks,
Stephen
signature.asc
De
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
> I even provided a repo @github where it was broken up into pieces that can be
> sanely reviewed.
You also gave the first person looking at the patch a hard time about
asking for it to be broken up; unnecessairly, imv. Thanks for breaking
2013-10-21 17:11 keltezéssel, Robert Haas írta:
On Mon, Oct 21, 2013 at 9:18 AM, Andres Freund wrote:
On 2013-10-21 09:15:36 -0400, Peter Eisentraut wrote:
On 10/21/13 1:31 AM, Andres Freund wrote:
The point of the CF is exactly that all
patches get at least one good round of review. Moving u
Vik,
* Vik Fearing (vik.fear...@dalibo.com) wrote:
> A parser refactoring broke my code. I reported it and it was promptly
> fixed. When the fix came up for review, I said it needed a regression
> test to prevent it from happening again and I was told by the author
> that such a test would be "f
On 10/21/2013 05:13 PM, Mike Blackwell wrote:
> Actually, I did call them out in the thread announcing the CF Wrap Up
> (http://www.postgresql.org/message-id/CAESHdJonURj3i9HR2w4e=ohep5hx7snqyydsgyweqqa+a3d...@mail.gmail.com).
>
>
> Looking back, it may have been better to post it as a separate t
On 10/21/2013 05:06 PM, Andres Freund wrote:
> On 2013-10-21 16:40:43 +0200, Hannu Krosing wrote:
>> On 10/18/2013 08:50 PM, Andres Freund wrote:
>>> On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
>> ...
2. If that seems too complicated, how about just logging the whole old
tuple for ve
On 2013-10-21 11:14:37 -0400, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund wrote:
> > I have a hard time to understand why you dislike it so much. Think of a
> > big schema where you want to add auditing via changeset
> > extraction. Because of problems with reindexing prima
On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi
wrote:
> From the following mail, copy behaviour between stdin and normal file having
> some inconsistency.
>
>
> http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com
>
>
>
> The issue was that if copy execute "from stdin", then it
On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund wrote:
> I have a hard time to understand why you dislike it so much. Think of a
> big schema where you want to add auditing via changeset
> extraction. Because of problems with reindexing primary key you've just
> used candidate keys so far. Why shou
Actually, I did call them out in the thread announcing the CF Wrap Up (
http://www.postgresql.org/message-id/CAESHdJonURj3i9HR2w4e=ohep5hx7snqyydsgyweqqa+a3d...@mail.gmail.com).
Looking back, it may have been better to post it as a separate thread, but
I'm not confident that would have made much
On Mon, Oct 21, 2013 at 9:18 AM, Andres Freund wrote:
> On 2013-10-21 09:15:36 -0400, Peter Eisentraut wrote:
>> On 10/21/13 1:31 AM, Andres Freund wrote:
>> > The point of the CF is exactly that all
>> > patches get at least one good round of review. Moving unreviewed patches
>> > to the next CF
Heikki Linnakangas writes:
> On 21.10.2013 16:15, Peter Eisentraut wrote:
>> What is the alternative?
> If no-one really cares enough about a patch to review it, mark it as
> "rejected, because no-one but the patch author cares". Harsh, but that's
> effectively what pushing to the next commitfe
On 2013-10-21 16:40:43 +0200, Hannu Krosing wrote:
> On 10/18/2013 08:50 PM, Andres Freund wrote:
> > On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
> ...
> >> 2. If that seems too complicated, how about just logging the whole old
> >> tuple for version 1?
> > I think that'd make the patch much l
On 10/21/2013 03:56 PM, Heikki Linnakangas wrote:
>
> I feel guilty to complain, while not actually volunteering to be a
> commitfest manager myself, but I wish the commitfest manager would be
> more aggressive in nagging, pinging and threatening people to review
> stuff. If nothing else, always fe
On 10/20/2013 07:52 PM, Noah Misch wrote:
Consider this list of new functions in their place:
lo_create(oid, bytea) RETURNS oid -- new LO with content (similar to make_lo)
lo_get(oid) RETURNS bytea-- read entire LO (same as
load_lo)
lo_get(oid, bigint, int) RETURNS byt
On 10/18/2013 08:50 PM, Andres Freund wrote:
> On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
...
>> 2. If that seems too complicated, how about just logging the whole old
>> tuple for version 1?
> I think that'd make the patch much less useful because it bloats WAL
> unnecessarily for the primar
On 2013-10-21 09:32:12 -0400, Robert Haas wrote:
> On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund wrote:
> > I know of the following solutions:
> > 1) Don't allow VACUUM FULL on catalog tables if wal_level = logical.
> > 2) Make VACUUM FULL prevent DDL and then wait till all changestreams
> >h
On 21.10.2013 16:15, Peter Eisentraut wrote:
On 10/21/13 1:31 AM, Andres Freund wrote:
The point of the CF is exactly that all
patches get at least one good round of review. Moving unreviewed patches
to the next CF will let them just suffer the same fate there.
Agreed. People have different vi
On 2013-10-21 09:40:13 -0400, Robert Haas wrote:
> On Fri, Oct 18, 2013 at 2:50 PM, Andres Freund wrote:
> > How about modifying the selection to go from:
> > * all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
> > * index chosen by ALTER TABLE ... REPLICA IDENTITY USING indexname
> > * [
On Mon, Oct 21, 2013 at 3:42 PM, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 9:36 AM, Peter Eisentraut wrote:
>> On 10/19/13 8:22 PM, Peter Geoghegan wrote:
>>> I don't think it's a problem that
>>> autovacuum_work_mem is kind of similar to vacuum_mem in name.
>>> maintenance_work_mem was last s
On Mon, Oct 21, 2013 at 9:36 AM, Peter Eisentraut wrote:
> On 10/19/13 8:22 PM, Peter Geoghegan wrote:
>> I don't think it's a problem that
>> autovacuum_work_mem is kind of similar to vacuum_mem in name.
>> maintenance_work_mem was last spelt vacuum_mem about 10 years ago.
>> Enough time has pass
On Thu, Oct 10, 2013 at 1:41 PM, Pavan Deolasee
wrote:
>
>
> Not that I can find any flaw in the OP's patch, but given the major
> objections and my own nervousness about documenting this new "failback safe"
> standby mode, I am also inclining to improve pg_rewind or whatever it takes
> to get it
On Fri, Oct 18, 2013 at 2:50 PM, Andres Freund wrote:
> How about modifying the selection to go from:
> * all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
> * index chosen by ALTER TABLE ... REPLICA IDENTITY USING indexname
> * [later, maybe] ALTER TABLE ... REPLICA IDENTITY (cola, colb)
On 10/19/13 8:22 PM, Peter Geoghegan wrote:
> I don't think it's a problem that
> autovacuum_work_mem is kind of similar to vacuum_mem in name.
> maintenance_work_mem was last spelt vacuum_mem about 10 years ago.
> Enough time has passed that I think it very unlikely that someone
> might conflate t
On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund wrote:
> I know of the following solutions:
> 1) Don't allow VACUUM FULL on catalog tables if wal_level = logical.
> 2) Make VACUUM FULL prevent DDL and then wait till all changestreams
>have decoded up to the current point.
> 3) don't delete the
Peter Eisentraut wrote:
>> --- 3511,3534
>> }
>>
>> /*
>> ! * Perform an explicit anonymous bind.
>> ! * This is not necessary in principle, but we want to set a timeout
>> ! * of PGLDAP_TIMEOUT seconds and return 2 if the connection fails.
>> ! * Unfortunately there
On 2013-10-21 09:15:36 -0400, Peter Eisentraut wrote:
> On 10/21/13 1:31 AM, Andres Freund wrote:
> > The point of the CF is exactly that all
> > patches get at least one good round of review. Moving unreviewed patches
> > to the next CF will let them just suffer the same fate there.
>
> What is t
On 10/21/13 1:31 AM, Andres Freund wrote:
> The point of the CF is exactly that all
> patches get at least one good round of review. Moving unreviewed patches
> to the next CF will let them just suffer the same fate there.
What is the alternative?
--
Sent via pgsql-hackers mailing list (pgsql-h
On Fri, Oct 18, 2013 at 7:21 PM, Jim Nasby wrote:
> Yeah, but hasn't every case of this that we've run into been directly
> related to casting problems, and not function or operator preference?
No.
> Something else I'm wondering is if priority should actually be something
> that's numbered inste
make distclean & ./configure & make & sudo make install
helped.
Cheers,
Colin
On 21 October 2013 14:25, Michael Paquier wrote:
> On Mon, Oct 21, 2013 at 9:09 PM, Colin 't Hart
> wrote:
> > git status says that I'm on branch master.
> > psql reports 9.3devel, yet I expected it to report 9.4
On Mon, Oct 21, 2013 at 9:09 PM, Colin 't Hart wrote:
> git status says that I'm on branch master.
> psql reports 9.3devel, yet I expected it to report 9.4devel
>
> Is this expected behaviour? I've looked at the developer's FAQ and Wiki but
> couldn't find anything about this.
You should check you
Hi,
git status says that I'm on branch master.
psql reports 9.3devel, yet I expected it to report 9.4devel
Is this expected behaviour? I've looked at the developer's FAQ and Wiki but
couldn't find anything about this.
Cheers,
Colin
On 10/21/2013 06:24 AM, David Fetter wrote:
> On Sat, Oct 19, 2013 at 01:56:23PM -0400, Peter Eisentraut wrote:
>> I'd also take a look at ditaa, which might make this even simpler.
> If we manage to keep Java out of our build toolchain, we will be much
> the better for it.
Amen.
--
Vik
--
S
(2013/10/18 22:21), Andrew Dunstan wrote:
> If we're going to extend pg_stat_statements, even more than min and max
> I'd like to see the standard deviation in execution time.
OK. I do! I am making some other patches, please wait more!
Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center.;
(2013/10/19 14:58), Amit Kapila wrote:
> On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
> wrote:
> I think in general also snappy is mostly preferred for it's low CPU
> usage not for compression, but overall my vote is also for snappy.
I think low CPU usage is the best important factor in WAL
On Tue, 2013-10-15 at 23:11 -0400, Peter Eisentraut wrote:
> Updated patch attached.
Committed with some further tweaks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2013/10/02 18:57), Michael Paquier wrote:
wrote:
Who is pgFoundery administrator or board member now? I would like to send e-mail
them. At least, it does not have information and support page in pgFoundery
homepage.
Why don't you consider github as a potential solution?
It is because github
94 matches
Mail list logo
