On 26/09/17 20:44, Mark Kirkwood wrote:
$ pg_basebackup -D .
WARNING: could not read symbolic link "pg_tblspc/space1": Invalid
argument
pg_basebackup: directory "/data0/pgdata/11/pg_tblspc/space1" exists
but is not empty
pg_basebackup: removing contents of data
On 30/09/17 06:43, Robert Haas wrote:
On Fri, Sep 29, 2017 at 2:06 AM, Michael Paquier
wrote:
My tendency about this patch is still that it should be rejected. This
is presenting additional handling for no real gain.
I vehemently disagree. If the server lets you
On 29/04/15 09:35, Bruce Momjian wrote:
On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote:
This way, both pg_dump and pg_upgrade will issue warnings, though, of
course, those warnings can be ignored. I am hopeful these two warnings
will be sufficient and we will not need make
On 26/08/17 12:18, Simon Riggs wrote:
On 25 August 2017 at 20:53, Tom Lane wrote:
Greg Stark writes:
I think this is a particularly old piece of code and we're lucky the
default heuristics have served well for all this time because I doubt
many people
On 21/07/17 15:58, Joshua D. Drake wrote:
On 07/19/2017 07:57 PM, Tom Lane wrote:
Peter Geoghegan writes:
My argument for the importance of index bloat to the more general
bloat problem is simple: any bloat that accumulates, that cannot be
cleaned up, will probably accumulate
On 16/07/17 05:24, David Fetter wrote:
On Fri, Jul 14, 2017 at 09:49:25PM -0500, Robert Haas wrote:
On Mon, Jul 10, 2017 at 5:46 PM, David Fetter wrote:
With utmost respect, it's less messy than adding '!' to the already
way too random and mysterious syntax of psql's \
On 07/07/17 19:54, Michael Banck wrote:
On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote:
On 07/07/17 13:29, Amit Langote wrote:
Someone complained about this awhile back [1]. And then it came up again
[2], where Noah appeared to take a stance that partitions should be
visible
On 07/07/17 13:29, Amit Langote wrote:
Someone complained about this awhile back [1]. And then it came up again
[2], where Noah appeared to take a stance that partitions should be
visible in views / output of commands that list "tables".
Although I too tend to prefer not filling up the \d
I've been trying out the new partitioning in version 10. Firstly, I must
say this is excellent - so much nicer than the old inheritance based method!
My only niggle is the display of partitioned tables via \d etc. e.g:
part=# \d
List of relations
Schema | Name
On 15/06/17 11:10, Tom Lane wrote:
Jeff Janes writes:
On Sat, Jun 10, 2017 at 7:42 AM, Tom Lane wrote:
In the second place, this really fails to respond to what I'd call
the main usability problem with \dRp+, which is that the all-tables
property is
On 06/06/17 10:12, Gavin Flower wrote:
On 06/06/17 09:41, Mark Kirkwood wrote:
On 05/06/17 09:30, Tom Lane wrote:
I've been thinking about the behavior discussed in
https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org
and it seems to me
On 05/06/17 09:30, Tom Lane wrote:
I've been thinking about the behavior discussed in
https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org
and it seems to me that there are a couple of things we ought to do about
it.
First, I think we need a larger
On 05/06/17 13:08, Mark Kirkwood wrote:
On 05/06/17 00:04, Erik Rijkers wrote:
On 2017-05-31 16:20, Erik Rijkers wrote:
On 2017-05-31 11:16, Petr Jelinek wrote:
[...]
Thanks to Mark's offer I was able to study the issue as it happened
and
found the cause of this.
[0001-Improve-handover
On 05/06/17 00:04, Erik Rijkers wrote:
On 2017-05-31 16:20, Erik Rijkers wrote:
On 2017-05-31 11:16, Petr Jelinek wrote:
[...]
Thanks to Mark's offer I was able to study the issue as it happened and
found the cause of this.
[0001-Improve-handover-logic-between-sync-and-apply-worker.patch]
On 03/06/17 11:10, Petr Jelinek wrote:
On 02/06/17 22:29, Petr Jelinek wrote:
On 02/06/17 08:55, Mark Kirkwood wrote:
On 02/06/17 17:11, Erik Rijkers wrote:
On 2017-06-02 00:46, Mark Kirkwood wrote:
On 31/05/17 21:16, Petr Jelinek wrote:
I'm seeing a new failure with the patch applied
On 02/06/17 17:11, Erik Rijkers wrote:
On 2017-06-02 00:46, Mark Kirkwood wrote:
On 31/05/17 21:16, Petr Jelinek wrote:
I'm seeing a new failure with the patch applied - this time the
history table has missing rows. Petr, I'll put back your access :-)
Is this error during 1-minute runs
On 31/05/17 21:16, Petr Jelinek wrote:
On 29/05/17 23:06, Mark Kirkwood wrote:
On 29/05/17 23:14, Petr Jelinek wrote:
On 29/05/17 03:33, Jeff Janes wrote:
What would you want to look at? Would saving the WAL from the master be
helpful?
Useful info is, logs from provider (mainly
On 29/05/17 23:14, Petr Jelinek wrote:
On 29/05/17 03:33, Jeff Janes wrote:
What would you want to look at? Would saving the WAL from the master be
helpful?
Useful info is, logs from provider (mainly the logical decoding logs
that mention LSNs), logs from subscriber (the lines about when
On 29/05/17 13:33, Jeff Janes wrote:
On Sun, May 28, 2017 at 3:17 PM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz <mailto:mark.kirkw...@catalyst.net.nz>>
wrote:
On 28/05/17 19:01, Mark Kirkwood wrote:
So running in cloud land now...so for no errors -
On 29/05/17 16:26, Erik Rijkers wrote:
On 2017-05-29 00:17, Mark Kirkwood wrote:
On 28/05/17 19:01, Mark Kirkwood wrote:
So running in cloud land now...so for no errors - will update.
The framework ran 600 tests last night, and I see 3 'NOK' results, i.e
3 failed test runs (all scale 25
On 28/05/17 19:01, Mark Kirkwood wrote:
So running in cloud land now...so for no errors - will update.
The framework ran 600 tests last night, and I see 3 'NOK' results, i.e 3
failed test runs (all scale 25 and 8 pgbench clients). Given the way the
test decides on failure (gets tired
On 27/05/17 20:30, Erik Rijkers wrote:
Here is what I have:
instances.sh:
starts up 2 assert enabled sessions
instances_fast.sh:
alternative to instances.sh
starts up 2 assert disabled 'fast' sessions
testset.sh
loop to call pgbench_derail2.sh with varying params
Sorry - I see you have done this already.
On 28/05/17 11:15, Mark Kirkwood wrote:
Interesting - might be good to see your test script too (so we can
better understand how you are deciding if the runs are successful or
not).
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Interesting - might be good to see your test script too (so we can
better understand how you are deciding if the runs are successful or not).
Also, any idea which rows are different? If you want something out of
the box that will do that for you see DBIx::Compare.
regards
Mark
On
On 26/05/17 20:09, Erik Rijkers wrote:
The idea is simple enough:
startup instance1
startup instance2 (on same machine)
primary: init pgbench tables
primary: add primary key to pgbench_history
copy empty tables to replica by dump/restore
primary: start publication
replica: start subscription
On 26/05/17 20:09, Erik Rijkers wrote:
On 2017-05-26 09:40, Simon Riggs wrote:
If we can find out what the bug is with a repeatable test case we can
fix it.
Could you provide more details? Thanks
I will, just need some time to clean things up a bit.
But what I would like is for someone
On 25/03/17 07:52, Peter Eisentraut wrote:
On 3/24/17 10:09, Petr Jelinek wrote:
On 24/03/17 15:05, Peter Eisentraut wrote:
On 3/23/17 19:32, Petr Jelinek wrote:
Yes, I also forgot to check if the table actually exists on subscriber
when fetching them in CREATE SUBSCRIPTION (we have check
On 24/03/17 12:32, Petr Jelinek wrote:
On 24/03/17 00:14, Mark Kirkwood wrote:
On 24/03/17 02:00, Peter Eisentraut wrote:
On 3/21/17 21:38, Peter Eisentraut wrote:
This patch is looking pretty good to me, modulo the failing pg_dump
tests.
Attached is a fixup patch. I have mainly updated
On 24/03/17 02:00, Peter Eisentraut wrote:
On 3/21/17 21:38, Peter Eisentraut wrote:
This patch is looking pretty good to me, modulo the failing pg_dump tests.
Attached is a fixup patch. I have mainly updated some comments and
variable naming for (my) clarity. No functional changes.
On 15/03/17 06:29, Robert Haas wrote:
Great! I've committed the latest version of the patch, with some
cosmetic changes.
It would be astonishing if there weren't a bug or two left, but I
think overall this is very solid work, and I think it's time to put
this out there and see how things go.
Hi,
Thought I'd take a look at how this works (checking out current master).
You guys have manged to get this to the point where it is *ridiculously*
easy to set up a basic replication scenario - awesome i must say:
- change a few parameters on the master
On 23/11/16 16:31, Tom Lane wrote:
Robert Haas writes:
[ Let's invent Oracle-style UNDO logs ]
I dunno. I remember being told years ago, by an ex-Oracle engineer,
that he thought our approach was better. I don't recall all the details
of the conversation but I think
I see there are some patches for the putenv issue with Visual studio
2013 in progress on this list - it is probably best to work with the
author to see if 2015 has any new issues and keep all changes for that
*out* of the cmake patches.
regards
Mark
On 16/11/16 21:22, Yury Zhuravlev
Yeah, there seems to be a lot of these. Looking through them almost all
concern the addition of piece of code to wrap putenv. e.g:
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1350,7 +1350,7 @@ exec_command(const char *cmd,
char *newval;
I had a bit a play around to see if I could get this building properly
again with v10 (i.e master). I've attached a minimal *incremental* patch
that needs to be applied after v1. This gets everything under the src
tree building (added the new file_utils.c and reordered some link libs
and
On 11/11/16 08:15, Yury Zhuravlev wrote:
Craig Ringer wrote:
So personally I think it'd be fine if a cmake build defaulted to
finding and using what it could, but offered a --minimal mode or
whatever that gets us just core postgres + whatever we enable
explicitly. But our current behaviour is
On 25/09/16 18:18, Amit Kapila wrote:
On Sat, Sep 24, 2016 at 10:49 PM, Greg Stark wrote:
On Thu, Sep 22, 2016 at 3:23 AM, Tom Lane wrote:
But to kick the hash AM as such to the curb is to say
"sorry, there will never be O(1) index lookups in Postgres".
On 17/09/16 06:38, Andres Freund wrote:
On 2016-09-16 09:12:22 -0700, Jeff Janes wrote:
On Thu, Sep 15, 2016 at 7:23 AM, Andres Freund wrote:
One earlier question about this is whether that is actually a worthwhile
goal. Are the speed and space benefits big enough in
On 16/09/16 18:35, Amit Kapila wrote:
On Thu, Sep 15, 2016 at 7:53 PM, Andres Freund wrote:
Hi,
On 2016-05-10 17:39:22 +0530, Amit Kapila wrote:
For making hash indexes usable in production systems, we need to improve
its concurrency and make them crash-safe by WAL
On 02/09/16 15:19, Andres Freund wrote:
On 2016-09-02 08:31:42 +0530, Robert Haas wrote:
I wonder whether we ought to just switch from the consistent method to
the semiconsistent method and call it good.
+1. I think, before long, we're going to have to switch away from having
locks &
On 13/09/16 01:20, Jesper Pedersen wrote:
On 09/01/2016 11:55 PM, Amit Kapila wrote:
I have fixed all other issues you have raised. Updated patch is
attached with this mail.
The following script hangs on idx_val creation - just with v5, WAL patch
not applied.
Are you sure it is actually
On 11/09/16 19:16, Mark Kirkwood wrote:
On 11/09/16 17:01, Amit Kapila wrote:
...Do you think we can do some read-only
workload benchmarking using this server? If yes, then probably you
can use concurrent hash index patch [1] and cache the metapage patch
[2] (I think Mithun needs to rebase
On 11/09/16 17:01, Amit Kapila wrote:
On Sun, Sep 11, 2016 at 4:10 AM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
performed several 10 hour runs on size 100 database using 32 and 64 clients.
For the last run I rebuilt with assertions enabled. No hangs or assertion
fa
On 09/09/16 14:50, Mark Kirkwood wrote:
Yeah, good suggestion about replacing (essentially) all the indexes
with hash ones and testing. I did some short runs with this type of
schema yesterday (actually to get a feel for if hash performance vs
btree was compareable - does seem tp
On 09/09/16 07:09, Jeff Janes wrote:
On Wed, Sep 7, 2016 at 3:29 AM, Ashutosh Sharma > wrote:
> Thanks to Ashutosh Sharma for doing the testing of the patch and
> helping me in analyzing some of the above issues.
Hi All,
I
the
same problem or something else.
The test is rather awkward, it might be easier to just have me test it.
Okay, I have fixed this issue as explained above. Apart from that, I
have fixed another issue reported by Mark Kirkwood upthread and few
other issues found during internal testing
On 24/08/16 17:01, Mark Kirkwood wrote:
...actually I was wrong there, only 2 of them were the same. So I've
attached a new log of bt's of them all.
And I can reproduce with only 1 session, figured that might be a helpful
piece of the puzzle (trace attached).
$ pgbench -c 1 -T600
On 24/08/16 16:52, Mark Kirkwood wrote:
On 24/08/16 16:33, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz>
On 24/08/16 16:33, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
Can you get the call stacks?
For
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
On 24/08/16 12:09, Mark Kirkwood wrote:
On 23/08/16 15:24, Amit Kapila wrote:
Thoughts?
Note - To use this patch, first apply latest version of concurrent
hash
On 24/08/16 12:09, Mark Kirkwood wrote:
On 23/08/16 15:24, Amit Kapila wrote:
Thoughts?
Note - To use this patch, first apply latest version of concurrent
hash index patch [2].
[1] - https://commitfest.postgresql.org/10/647/
[2] -
https://www.postgresql.org/message-id/caa4ek1lkq_udism
On 23/08/16 15:24, Amit Kapila wrote:
Thoughts?
Note - To use this patch, first apply latest version of concurrent
hash index patch [2].
[1] - https://commitfest.postgresql.org/10/647/
[2] -
On 13/08/16 05:44, Jeff Janes wrote:
On Fri, Aug 12, 2016 at 1:40 AM, Mark Kirkwood
However your index rebuild gets you from 5 to 3 GB - does that really help
performance significantly?
It can make a big difference, depending on how much RAM you have.
Yeah - I suspect this is the issue
After examining the benchmark design - I see we are probably not being
helped by the repeated insertion of keys all of form 'userxxx'
leading to some page splitting.
However your index rebuild gets you from 5 to 3 GB - does that really
help performance significantly?
regards
Mark
On
On 03/08/16 02:27, Robert Haas wrote:
Personally, I think that incremental surgery on our current heap
format to try to fix this is not going to get very far. If you look
at the history of this, 8.3 was a huge release for timely cleanup of
dead tuple. There was also significant progress in
On 06/03/16 18:29, MauMau wrote:
> As I said in the previous greeting mail, I'd like to discuss how to
> expand PostgreSQL ecosystem. Here, ecosystem means "interoperability"
> -- the software products and cloud services which use/support
> PostgreSQL. If pgsql-advocacy or somewhere else is
On 16/02/16 20:01, Tatsuo Ishii wrote:
Tatsuo Ishii writes:
While reading planstats.sgml, I encounted a sentence which I don't
understand.
These numbers are current as of the last VACUUM or
ANALYZE on the table. The planner then fetches the
actual
On 16/02/16 12:46, David G. Johnston wrote:
On Mon, Feb 15, 2016 at 4:23 PM, Tatsuo Ishii >wrote:
While reading planstats.sgml, I encounted a sentence which I don't
understand.
These numbers are current as of the last VACUUM
On 01/09/15 21:41, Bruce Momjian wrote:
Well, reworking our partitioning system is one of the things required
for sharding, so at least we will clean up one mess while we create
another. ;-)
Seem my post to Josh Berkus just now --- I think if we don't use FDWs,
that sharding is such a limited
On 01/06/15 05:29, Joel Jacobson wrote:
While anyone who is familiar with postgres would never do something as
stupid as to delete pg_xlog,
according to Google, there appears to be a fair amount of end-users out
there having made the irrevocable mistake of deleting the precious
directory,
a
On 22/03/15 08:14, Jaime Casanova wrote:
El mar 21, 2015 2:00 AM, Mark Kirkwood mark.kirkw...@catalyst.net.nz
mailto:mark.kirkw...@catalyst.net.nz escribió:
On 21/03/15 19:28, Jaime Casanova wrote:
what about not removing it but not showing it in postgresql.conf? as a
side note, i
On 21/03/15 19:28, Jaime Casanova wrote:
On Fri, Mar 20, 2015 at 11:29 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Mar 21, 2015 at 2:47 AM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Mar 20, 2015 at 9:52 AM, Joshua D. Drake j...@commandprompt.com wrote:
There are just as
On 26/02/15 13:32, Simon Riggs wrote:
On 25 February 2015 at 23:30, Jim Nasby jim.na...@bluetreble.com wrote:
That said, I don't want to block this; I think it's useful. Though, perhaps
it would be better as an extension instead of in contrib? I don't think it
should be very version dependent?
On 25/02/15 12:47, Michael Paquier wrote:
On Wed, Feb 25, 2015 at 8:03 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz
wrote:
On 25/02/15 11:06, Ratay, Steve wrote:
I have checked out the pg_rewind code from
https://github.com/vmware
On 25/02/15 11:06, Ratay, Steve wrote:
I have checked out the pg_rewind code from
https://github.com/vmware/pg_rewind.git on the master branch and am using
PostgreSQL 9.4.1 source code to build against. When I try to compile
pg_rewind, I am getting the following errors. How can I resolve
Actually, code has moved to:
https://github.com/snaga/pqc
On 09/01/15 19:53, Mark Kirkwood wrote:
Also see:
https://code.google.com/p/pqc/
A project to implement a query cache using pgpool code, probably lots of
good ideas there.
Cheers
Mark
On 09/01/15 19:38, Tatsuo Ishii wrote:
Hi
Also see:
https://code.google.com/p/pqc/
A project to implement a query cache using pgpool code, probably lots of
good ideas there.
Cheers
Mark
On 09/01/15 19:38, Tatsuo Ishii wrote:
Hi,
pgpool-II (pgpool.net) does exactly the same thing.
It receive SELECT query from clients, 1) parse
On 23/12/14 22:36, Ravi Kiran wrote:
hi all,
Is postgres source code compatible with mysql database?? If it is, could
someone could give me some links so that I can do that.
I want to hack into the postgres source code, but as I am comfortable
with mysql, I want to use the mysql database not
On 19/12/14 20:48, Andres Freund wrote:
On 2014-12-18 10:02:25 -0800, Joshua D. Drake wrote:
I think a lot of hackers forget exactly how tender their egos are. Now I say
this knowing that a lot of them will go, Oh give me a break but as someone
who employs hackers, deals with open source AND
On 20/12/14 11:22, Joshua D. Drake wrote:
On 12/19/2014 12:28 AM, Mark Kirkwood wrote:
To me that's a bit over the top stereotyping.
+1
Having been mentioned one or two times myself - it was an unexpected
wow - cool rather than a grumpy/fragile I must be noticed thing. I
think some folk
On 18/10/14 07:13, Josh Berkus wrote:
CK,
Before we go any further on this, how is Vitesse currently licensed?
last time we talked it was still proprietary. If it's not being
open-sourced, we likely need to take discussion off this list.
+1
Guys, you need to 'fess up on the licensing!
On 04/10/14 11:21, Andres Freund wrote:
On 2014-10-03 18:16:28 -0400, Bruce Momjian wrote:
On Sat, Oct 4, 2014 at 12:13:00AM +0200, Andres Freund wrote:
Do we really want to expose a setting a few of us _might_ ask customers
to change?
They also will try that themselves. Our customers
On 04/10/14 12:10, Bruce Momjian wrote:
On Sat, Oct 4, 2014 at 12:00:36PM +1300, Mark Kirkwood wrote:
I don't think we can offer absolutely accurate tuning advice, but I'm
sure we can give some guidance. Let me try.
+1
I think it is ok to document our reason for providing the new GUC
On 24/09/14 11:29, Mingzhe Li wrote:
Hi experts,
I want to know what's the core function used in Postgres server? I am
looking for something corresponding to main() in a simple C program. I
want to know the file path and the function name. I am using Postgres
9.3.5, however I assume the core
On 14/09/14 20:43, Mark Kirkwood wrote:
On 14/09/14 20:24, Atri Sharma wrote:
How do you plan to do all that VACUUM does for this table then?
It seems to me that you are saying to VACUUM that it need not be
concerned with table 'A' and you are assuming ownership of all the tasks
performed
On 14/09/14 05:36, Rohit Goyal wrote:
Hi All,
I want to work on the code of intermediate dataset of select and update
query.
For example.
Rohit's salary has been updated 4 times, so it has 4 different version
of salary.
I want to select salary of person named Rohit. Now suppose , in
On 14/09/14 19:00, Amit Kapila wrote:
On Fri, Sep 12, 2014 at 11:09 PM, Gregory Smith
gregsmithpg...@gmail.com mailto:gregsmithpg...@gmail.com wrote:
This looks like it's squashed one of the very fundamental buffer
scaling issues though; well done Amit.
Thanks.
I'll go back to my notes
On 14/09/14 19:25, Atri Sharma wrote:
On Sunday, September 14, 2014, Mark Kirkwood
mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz
wrote:
On 14/09/14 05:36, Rohit Goyal wrote:
Hi All,
I want to work on the code of intermediate dataset of select
On 14/09/14 20:24, Atri Sharma wrote:
On Sun, Sep 14, 2014 at 1:30 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz
wrote:
On 14/09/14 19:25, Atri Sharma wrote:
On Sunday, September 14, 2014, Mark Kirkwood
mark.kirkw
On 14/09/14 20:11, Rohit Goyal wrote:
Hi Mark,
On Sun, Sep 14, 2014 at 8:57 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz
wrote:
Currently in Postgres, these intermediate versions all exist -
however a given session can only see one of them
On 14/09/14 21:18, Rohit Goyal wrote:
Hi Mark Atri, :)
Thanks for reply. But, I think i confused you. I am talking about access
using indexes. So, I assume that B+ tree store key-value pair where
rohit is the key and all the versions are its value.
Another way to think is I have a secondary
On 10/09/14 18:54, Amit Kapila wrote:
On Wed, Sep 10, 2014 at 5:46 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz
wrote:
In terms of the effect of the patch - looks pretty similar to the
scale 2000 results for read-write, but read-only is a different
On 05/09/14 23:50, Amit Kapila wrote:
On Fri, Sep 5, 2014 at 8:42 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz
wrote:
On 04/09/14 14:42, Amit Kapila wrote:
On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz
On 04/09/14 14:42, Amit Kapila wrote:
On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood mark.kirkw...@catalyst.net.nz
wrote:
Hi Amit,
Results look pretty good. Does it help in the read-write case too?
Last time I ran the tpc-b test of pgbench (results of which are
posted earlier in this thread
On 03/09/14 16:22, Amit Kapila wrote:
On Wed, Sep 3, 2014 at 9:45 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Aug 28, 2014 at 4:41 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
I have yet to collect data under varying loads, however I have
collected performance data for 8GB
On 02/09/14 21:25, Álvaro Hernández Tortosa wrote:
On 02/09/14 05:24, Craig Ringer wrote:
I couldn't disagree more.
If we were to implement anything, it'd be PL/PSM
(http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and
quirky as anything else the SQL committee has brought
On 02/09/14 15:46, Craig Ringer wrote:
was is exactly why we need a new language and that All the clumsy
stuff we cannot fix in plpgsql, can easily be fixed in plpgsql2, with
the most beautiful syntax we can come up with. But you haven't said HOW
you propose to fix this one case.
On 29/08/14 08:56, Alvaro Herrera wrote:
Robert Haas wrote:
I agree that you might not like that. But you might not like having
the table vacuumed slower than the configured rate, either. My
impression is that the time between vacuums isn't really all that
negotiable for some people. I had
On 27/08/14 10:27, Alvaro Herrera wrote:
Alvaro Herrera wrote:
So my proposal is a bit more complicated. First we introduce the notion
of a single number, to enable sorting and computations: the delay
equivalent, which is the cost_limit divided by cost_delay.
Here's a patch that implements
On 27/08/14 10:27, Alvaro Herrera wrote:
Alvaro Herrera wrote:
So my proposal is a bit more complicated. First we introduce the notion
of a single number, to enable sorting and computations: the delay
equivalent, which is the cost_limit divided by cost_delay.
Here's a patch that implements
On 19/08/14 23:14, Vivek Singh Raghuwanshi wrote:
Hi All,
Please let me know is that possible to use Openstack Trove with Postgres-XC.
With instances and Baremetal (after Juno Release).
I Know it is possible to use other medium like MySQL or PostgreSQL, but
i am not sure about XC.
AFAIK [1],
On 05/08/14 17:56, Mark Kirkwood wrote:
Adding in the 'if' in the float8 case increases run time to 4s. So looks
like plpgsql might have a slightly higher cost for handling added
conditionals. Be interesting to dig a bit more and see what is taking
the time.
Thinking about this a bit more
On 05/08/14 08:48, testman1316 wrote:
We am trying to get an idea of the raw performance of Oracle vs PostgreSQL.
We have extensive oracle experience but are new to PostgreSQL. We are going
to run lots of queries with our data, etc. But first we wanted to see just
how they perform on basic
On 26/07/14 21:05, Andres Freund wrote:
More advanced features, but with much more impact on the code, would be to
be able to change the size at database/table level.
That'd be pretty horrible because the size of pages in shared_buffers
wouldn't be uniform anymore.
Possibly stopping at
On 09/07/14 05:13, Josh Berkus wrote:
On 07/06/2014 01:27 AM, Christoph Berg wrote:
Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb.c-setup_config().
This
On 01/07/14 23:25, Heikki Linnakangas wrote:
On 07/01/2014 01:08 PM, Andres Freund wrote:
Hi,
Over at -performance Mark Kirkwood tested a recent version of this
(http://archives.postgresql.org/message-id/53B283F3.7020005%40catalyst.net.nz)
. I thought it's interesting to add the numbers
On 07/05/14 17:35, Peter Geoghegan wrote:
On Tue, May 6, 2014 at 10:20 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 6 May 2014 23:47, Josh Berkus j...@agliodbs.com wrote:
If you're going to make
an argument in favor of different tuning advice, then do it based on
something in which you
On 05/05/14 15:22, Amit Kapila wrote:
Here what I could understand is that sum of cost_limit for all
autovacuum workers should never exceed the value of
autovacuum_vacuum_cost_limit which seems to be always the
case in current code but same is not true for proposed patch.
Right, but have a
On 06/05/14 16:28, Amit Kapila wrote:
On Mon, May 5, 2014 at 11:57 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 05/05/14 15:22, Amit Kapila wrote:
Right, but have a look at the 1st message in this thread - the current
behavior (and to a large extent the above condition) means
This seems like a much better idea - whereas a single table, related to
nothing - on the other hand, is at best not very helpful (and it could
be argued, might contribute to teaching poor data data design).
Regards
Mark
On 23/04/14 19:13, Pavel Stehule wrote:
Hello
if you are thinking
1 - 100 of 509 matches
Mail list logo