(2013/10/02 18:57), Michael Paquier wrote:
kondo.mitsum...@lab.ntt.co.jp 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
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/19 14:58), Amit Kapila wrote:
On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp 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
(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.;
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
--
Sent
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 Mon, Oct 21, 2013 at 9:09 PM, Colin 't Hart colinth...@gmail.com 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
make distclean ./configure make sudo make install
helped.
Cheers,
Colin
On 21 October 2013 14:25, Michael Paquier michael.paqu...@gmail.com wrote:
On Mon, Oct 21, 2013 at 9:09 PM, Colin 't Hart colinth...@gmail.com
wrote:
git status says that I'm on branch master.
psql reports
On Fri, Oct 18, 2013 at 7:21 PM, Jim Nasby j...@nasby.net 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
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
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 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 is no standard
On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund and...@2ndquadrant.com 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)
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 the
On Fri, Oct 18, 2013 at 2:50 PM, Andres Freund and...@2ndquadrant.com 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
On Thu, Oct 10, 2013 at 1:41 PM, Pavan Deolasee
pavan.deola...@gmail.com 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
On Mon, Oct 21, 2013 at 9:36 AM, Peter Eisentraut pete...@gmx.net 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
On Mon, Oct 21, 2013 at 3:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 21, 2013 at 9:36 AM, Peter Eisentraut pete...@gmx.net 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.
On 2013-10-21 09:40:13 -0400, Robert Haas wrote:
On Fri, Oct 18, 2013 at 2:50 PM, Andres Freund and...@2ndquadrant.com 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
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
On 2013-10-21 09:32:12 -0400, Robert Haas wrote:
On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund and...@2ndquadrant.com 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
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 primary user
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
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 feel
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 less useful
Heikki Linnakangas hlinnakan...@vmware.com 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
On Mon, Oct 21, 2013 at 9:18 AM, Andres Freund and...@2ndquadrant.com 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
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:51 AM, Andres Freund and...@2ndquadrant.com 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
On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi
rajeev.rast...@huawei.com 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
On 2013-10-21 11:14:37 -0400, Robert Haas wrote:
On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund and...@2ndquadrant.com 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
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 version 1?
I
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
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
2013-10-21 17:11 keltezéssel, Robert Haas írta:
On Mon, Oct 21, 2013 at 9:18 AM, Andres Freund and...@2ndquadrant.com 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
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
* 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
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
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 announce and
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
could get to
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
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, that could be the
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 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 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.
That's
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
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
On Mon, Oct 21, 2013 at 5:27 AM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
(2013/10/02 18:57), Michael Paquier wrote:
kondo.mitsum...@lab.ntt.co.jp wrote:
Who is pgFoundery administrator or board member now? I would like to send
e-mail
them. At least, it does not have information
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
On Sat, Oct 5, 2013 at 7:54 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
MauMau escribió:
From: Alvaro Herrera alvhe...@2ndquadrant.com
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
Hello
2013/10/21 Andrew Dunstan and...@dunslane.net
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
On Mon, Oct 21, 2013 at 1:52 PM, Andres Freund and...@2ndquadrant.com 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
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)
On 2013-10-21 14:22:17 -0400, Robert Haas wrote:
On Mon, Oct 21, 2013 at 1:52 PM, Andres Freund and...@2ndquadrant.com 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
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
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 Mon, Oct 21, 2013 at 2:27 PM, Andres Freund and...@2ndquadrant.com 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
Josh Berkus j...@agliodbs.com 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
On Mon, Oct 21, 2013 at 2:48 PM, Peter Eisentraut pete...@gmx.net 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
On 11.10.2013 17:39, Alexander Korotkov wrote:
On Fri, Oct 11, 2013 at 5:56 PM, Heikki Linnakangashlinnakan...@vmware.com
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)
{
-
On Thu, Oct 10, 2013 at 3:57 PM, Heikki Linnakangas hlinnakan...@vmware.com
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 Vondrat...@fuzzy.cz
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 Linnakangashlinnakangas@**
vmware.com hlinnakan...@vmware.com
wrote:
2. I didn't understand this change:
@@
On 2013-10-21 14:50:54 -0400, Robert Haas wrote:
On Mon, Oct 21, 2013 at 2:27 PM, Andres Freund and...@2ndquadrant.com 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
Alexander Korotkov aekorot...@gmail.com 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
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
On Mon, Oct 21, 2013 at 11:53 AM, Josh Berkus j...@agliodbs.com 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
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 are
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,
--
Gavin Flower gavinflo...@archidevsys.co.nz 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
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
On Mon, Oct 21, 2013 at 2:57 PM, Josh Berkus j...@agliodbs.com 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
On Mon, Oct 21, 2013 at 4:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gavin Flower gavinflo...@archidevsys.co.nz 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
On Mon, Oct 21, 2013 at 1:36 PM, Robert Haas robertmh...@gmail.com 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
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 just pointing
On 22/10/13 09:01, Tom Lane wrote:
Gavin Flower gavinflo...@archidevsys.co.nz 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'
Tom Lane t...@sss.pgh.pa.us 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
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
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
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
On 10/21/2013 04:43 PM, Peter Geoghegan wrote:
On Mon, Oct 21, 2013 at 1:36 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Andrew Dunstan and...@dunslane.net 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
On 10/21/2013 07:29 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On Mon, Oct 21, 2013 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Oct 22, 2013 at 1:09 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On 22/10/13 13:26, Ants Aasma wrote:
On Tue, Oct 22, 2013 at 1:09 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On 22/10/13 13:26, Ants Aasma wrote:
On Tue, Oct 22, 2013 at 1:09 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Tue, Oct 22, 2013 at 4:00 AM, Gavin Flower
gavinflo...@archidevsys.co.nz 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
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 Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
(2013/10/19 14:58), Amit Kapila wrote:
On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
In general, my thinking is that we should prefer compression to reduce
IO (WAL
On Tue, Oct 22, 2013 at 12:47 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
(2013/10/19 14:58), Amit Kapila wrote:
On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
In
On Tue, Oct 22, 2013 at 9:22 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Oct 22, 2013 at 12:47 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
(2013/10/19 14:58), Amit Kapila wrote:
On Tue, Oct 15,
On Mon, Oct 21, 2013 at 10:54 AM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 20 October 2013 12:06 Amit Kapila wrote:
On Tue, Oct 15, 2013 at 3:37 PM, Haribabu kommi haribabu.ko...@huawei.com
wrote:
On 12 October 2013 11:30 Tom Lane wrote:
Haribabu kommi haribabu.ko...@huawei.com
2013/10/21 Noah Misch n...@leadboat.com
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
94 matches
Mail list logo
