On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
> I also think the async I/O is the way to go. Luckily that has already been
> done
> in the pgjdbc-ng (https://github.com/impossibl/pgjdbc-ng), built on top
> of netty java NIO library. It has quite good feature parity with the original
> pgjdbc driv
On 11/03/2014 07:05 AM, Scott Harrington wrote:
> This avoids the need for a Future, and avoids the client having to
> loop/sleep until done.
A Future is the logical way to represent an asynchronous operation in
Java. Why implement something else that doesn't fit into existing
libraries and tools
On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
> I do not quite grasp why not sending Sync is so important.
Well, at the moment the PgJDBC driver relies on the following flow to
manage its buffers and avoid a logjam where both server and client are
waiting for the other to consume input:
* Send so
On 11/03/2014 07:05 AM, Scott Harrington wrote:
> I looked over your patch. Your list of ResultHandlerHolders seems to be
> the right direction, but as Tom Lane mentioned there may need to be some
> way to ensure the statements are all in the same transaction.
Why go down this track, when we alre
Josh,
Do you have a list of what needs to be done to keep the MONEY type?
What is wrong with it?
Thanks,
-cktan
On Mon, Nov 3, 2014 at 10:30 PM, Feng Tian wrote:
> Hi,
>
> This is Feng from Vitesse. Performance different between Money and Numeric
> is *HUGE*. For TPCH Q1, the performance di
On 11/03/2014 03:41 AM, Tom Lane wrote:
> Nothing that I recall at the moment, but there is certainly plenty of
> stuff of dubious quality in there. I'd argue that chkpass, intagg,
> intarray, isn, spi, and xml2 are all in worse shape than the money type.
What's wrong with intarray?
I'm aware of
Hi,
This is Feng from Vitesse. Performance different between Money and
Numeric is *HUGE*. For TPCH Q1, the performance difference is 5x for
stock postgres, and ~20x for vitesse.
Stock postgres, for my laptop, TPCH 1G, Q1, use money type ~ 9s, use
Numeric (15, 2) is ~53s.
Kevin,
test=# do $$
Hello ,
Please find updated patch with the review comments given above implemented.
The compressed data now includes all backup blocks and their headers except
the header of first backup block in WAL record. The first backup block
header in WAL record is used to store the compression information.
On Mon, Nov 03, 2014 at 04:40:39PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > I thank you for this research, but I suggest that we ship 9.4 as is,
> > that is with requiring IPC::Run and --enable-* option. All the possible
> > alternatives will clearly need more rounds of portability t
Michael Paquier writes:
> There is as well another way: finally support WAL-logging for hash indexes.
Sure, but that's a bit easier said than done. I think Robert looked into
that a year or two back and found some stumbling blocks that it wasn't
obvious how to surmount. I do hope it will happen
Josh Berkus writes:
> On 11/02/2014 11:41 AM, Tom Lane wrote:
>> Nothing that I recall at the moment, but there is certainly plenty of
>> stuff of dubious quality in there. I'd argue that chkpass, intagg,
>> intarray, isn, spi, and xml2 are all in worse shape than the money type.
> Why are we ho
m...@bloodnok.com writes:
> I have a script (below) that sets and resets the tablespace for a database
> and drops and recreates a composite type. The script fails when trying to
> re-create the previously dropped composite type because the type has
> apparently been magically resuscitated by chan
(2014/10/30 21:30), Fujii Masao wrote:
On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita
wrote:
Here are my review comments.
* The patch applies cleanly and make and make check run successfully. I
think that the patch is mostly good.
Thanks! Attached is the updated version of the patch.
Th
On Sun, Nov 2, 2014 at 2:30 AM, Tom Lane wrote:
> In the case of hash indexes, because we still have to have the hash
> opclasses in core, there's no way that it could be pushed out as an
> extension module even if we otherwise had full support for AMs as
> extensions. So what I hear you proposi
On 11/02/2014 11:41 AM, Tom Lane wrote:
> Nothing that I recall at the moment, but there is certainly plenty of
> stuff of dubious quality in there. I'd argue that chkpass, intagg,
> intarray, isn, spi, and xml2 are all in worse shape than the money type.
Why are we holding on to xml2 again?
FWI
On Tue, Nov 4, 2014 at 10:40 AM, Demai Ni wrote:
> hi, hackers,
>
> I am looking for a simple way to pass a value(ideally a hashtable, and use
> a string for easy implementation for now), that is generated by coordinator
> node, and pass it to all data nodes. Plans may be one approach, I am just
On 11/04/2014 09:10 AM, Tom Lane wrote:
> Mikko Tiihonen writes:
>> I do not quite grasp why not sending Sync is so important. My proof of
>> concept setup was for queries with autocommit enabled.
>
> [snip] It'll be very much like
> sending a fixed (predetermined) SQL script to the server using
On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
> > The performance of our numeric vs Oracle's was a common complaint when
> > I was at EnterpriseDB (in 2007).
> >
> > Perhaps numeric's performance could be greatly improved in cases where
> > the precision is low enough to map to an
hi, hackers,
I am looking for a simple way to pass a value(ideally a hashtable, and use
a string for easy implementation for now), that is generated by coordinator
node, and pass it to all data nodes. Plans may be one approach, I am just
wondering whether there is a simpler hook?
Many thanks for
On 11/03/2014 05:24 PM, Josh Berkus wrote:
> BTW, the reason I started poking into this was a report from a user that
> they have a pg_multixact directory which is 21GB in size, and is 2X the
> size of the database.
>
> Here's XID data:
>
> Latest checkpoint's NextXID: 0/1126461940
> Lat
On 11/03/2014 05:06 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> Hackers,
>>
>> I'm looking at a couple of high-transaction-rate and high-FK-conflict
>> rate servers where pg_multixact has grown to be more than 1GB in size.
>> One such server doesn't appear to be having any notable issues with
Mikko Tiihonen writes:
> I do not quite grasp why not sending Sync is so important. My proof of
> concept setup was for queries with autocommit enabled.
The point is that that will be very, very much harder to use than doing
it the other way. It's fairly easy to reason about the results of
sing
Josh Berkus wrote:
> Hackers,
>
> I'm looking at a couple of high-transaction-rate and high-FK-conflict
> rate servers where pg_multixact has grown to be more than 1GB in size.
> One such server doesn't appear to be having any notable issues with
> vacuuming, and the oldest mxid on the system is a
Jeff Janes wrote:
> On Mon, Nov 3, 2014 at 2:18 PM, Alvaro Herrera
> wrote:
> I get a couple compiler warnings with this:
>
> brin.c: In function 'brininsert':
> brin.c:97: warning: 'tupcxt' may be used uninitialized in this function
> brin.c:98: warning: 'oldcxt' may be used uninitialized in th
On Mon, Nov 3, 2014 at 7:25 PM, Alexey Vasiliev wrote:
>
>
>
>
> Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello <
fabriziome...@gmail.com>:
> >
> > >
> > > Should I change my patch and send it by email? And also as I
understand I should change message ID for
https://commitfest.postgresq
Hackers,
I'm looking at a couple of high-transaction-rate and high-FK-conflict
rate servers where pg_multixact has grown to be more than 1GB in size.
One such server doesn't appear to be having any notable issues with
vacuuming, and the oldest mxid on the system is about 47m old. VACUUM
FREEZEing
On Mon, Nov 3, 2014 at 2:18 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > [lots]
>
> I have fixed all these items in the attached, thanks -- most
> user-visible change was the pageinspect 1.3 thingy. pg_upgrade from 1.2
> works fine now. I also fixed some things Heikki noted, mainly avoid
> Craig Ringer wrote:
> On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
> > Is the following summary correct:
> > - the network protocol supports pipelinings
> Yes.
>
> All you have to do is *not* send a Sync message and be aware that the
> server will discard all input until the next Sync, so pipel
On 03/11/14 22:19, Tom Lane wrote:
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= writes:
IMHO, from a user perspective the transaction begins when the BEGIN
command is issued. If I really want to see a "frozen" view of the
database before any real SELECT, I have to issue another query li
On Mon, Nov 3, 2014 at 3:26 PM, Peter Eisentraut wrote:
> On 11/1/14 8:04 AM, Petr Jelinek wrote:
>> On second thought, maybe those should be pg_get_transaction_committs,
>> pg_get_transaction_committs_data, etc.
>
> Please don't name anything "committs". That looks like a misspelling of
> someth
Alvaro Herrera wrote:
> There is a real advantage of money over numeric in the performance
> front. I haven't measured it, but suffice to say that money uses
> integer operations which map almost directly to CPU instructions,
> whereas numeric needs to decode from our varlena base-1 digit
>
> The performance of our numeric vs Oracle's was a common complaint when
> I was at EnterpriseDB (in 2007).
>
> Perhaps numeric's performance could be greatly improved in cases where
> the precision is low enough to map to an int/bigint. That would get us
> closer to eliminating money as well as g
On 03/11/14 22:26, Peter Eisentraut wrote:
On 11/1/14 8:04 AM, Petr Jelinek wrote:
On second thought, maybe those should be pg_get_transaction_committs,
pg_get_transaction_committs_data, etc.
Please don't name anything "committs". That looks like a misspelling of
something.
There is nothing
On 11/03/2014 04:44 PM, Peter Eisentraut wrote:
On 10/29/14 8:42 AM, Robert Haas wrote:
I'm sympathetic to that line of reasoning, but I really think that if
you want to keep this infrastructure, it needs to be made portable.
Let me clarify that this was my intention. I have looked at many te
On 10/29/14 8:42 AM, Robert Haas wrote:
> I'm sympathetic to that line of reasoning, but I really think that if
> you want to keep this infrastructure, it needs to be made portable.
Let me clarify that this was my intention. I have looked at many test
frameworks, many of which are much nicer than
Peter Eisentraut writes:
> I thank you for this research, but I suggest that we ship 9.4 as is,
> that is with requiring IPC::Run and --enable-* option. All the possible
> alternatives will clearly need more rounds of portability testing. We
> can then evaluate these changes for 9.5 in peace.
I
On 11/2/14 2:00 PM, Noah Misch wrote:
>> Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
>> Thanks for investigating. So, surviving options include:
>>
>> 1. Require IPC::Run.
>> 2. Write our own run() that reports the raw exit code.
>> 3. Distill the raw exit code from t
On 11/1/14 8:04 AM, Petr Jelinek wrote:
> On second thought, maybe those should be pg_get_transaction_committs,
> pg_get_transaction_committs_data, etc.
Please don't name anything "committs". That looks like a misspelling of
something.
There is nothing wrong with
pg_get_transaction_commit_times
Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello
:
>
> >
> > Should I change my patch and send it by email? And also as I understand I
> > should change message ID for
> > https://commitfest.postgresql.org/action/patch_view?id=1636 , isn't it?
> >
>
> You should just send another
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= writes:
> IMHO, from a user perspective the transaction begins when the BEGIN
> command is issued. If I really want to see a "frozen" view of the
> database before any real SELECT, I have to issue another query like
> "SELECT 1". This seems odd
>
> Should I change my patch and send it by email? And also as I understand I
should change message ID for
https://commitfest.postgresql.org/action/patch_view?id=1636, isn't it?
>
You should just send another version of your patch by email and add a new
"comment" to commit-fest using the "Patch" c
Peter Eisentraut writes:
> On 11/3/14 3:11 PM, Tom Lane wrote:
>> If there's a commit that goes with this statement, you neglected to push
>> it...
> Are you not seeing this in configure.in:
> AC_CHECK_PROGS(PROVE, prove)
> if test -z "$PROVE"; then
> AC_MSG_ERROR([prove not found])
Oh
On 11/3/14 3:11 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 11/2/14 11:36 AM, Tom Lane wrote:
>>> Committed patch looks good, but should we also add the stanza we discussed
>>> in Makefile.global.in concerning defining $(prove) in terms of "missing"
>>> if we didn't find it? I think the
Abhijit Menon-Sen writes:
> Earlier, I was using a combination of check and assign hooks to convert
> names to OIDs, but (as Andres pointed out) that would have problems with
> cache invalidations. I was even playing with caching membership lookups,
> but I ripped out all that code.
> In the atta
Hi.
I could actually use some comments on the approach. I've attached
a prototype I've been working on (which is a cut down version of
my earlier code; but it's not terribly interesting and you don't
need to read it to comment on my questions below). The attached
patch does the following:
1. Adds
On Wed, Oct 15, 2014 at 1:11 PM, Jeff Janes wrote:
> On Fri, Aug 8, 2014 at 12:08 AM, Guillaume Lelarge > wrote:
>
>> Hi,
>>
>> As part of our monitoring work for our customers, we stumbled upon an
>> issue with our customers' servers who have a wal_keep_segments setting
>> higher than 0.
>>
>>
Jim Nasby wrote:
> On 11/1/14, 8:41 AM, Petr Jelinek wrote:
> >Well this is not BDR specific thing, the idea is that with logical
> >replication, commit timestamp is not enough for conflict handling, you also
> >need to have additional info in order to identify some types of conflicts
> >conflic
Mon, 03 Nov 2014 14:36:33 -0500 от Peter Eisentraut :
> On 11/3/14 6:04 AM, Alexey Vasiliev wrote:
> > 3. What the patch does in a short paragraph: This patch should add
> > option recovery_timeout, which help to control timeout of
> > restore_command nonzero status code. Right now default
On 11/3/14, 1:34 PM, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, Nov 03, 2014 at 01:54:09PM +0100, Michael Banck wrote:
As an additional datapoint, Vitesse Data changed the DB schema from
NUMERIC to MONEY for their TPCH benchmark for performance reasons: "The
modification to data types is
Peter Eisentraut writes:
> On 11/2/14 11:36 AM, Tom Lane wrote:
>> Committed patch looks good, but should we also add the stanza we discussed
>> in Makefile.global.in concerning defining $(prove) in terms of "missing"
>> if we didn't find it? I think the behavior of HEAD when you ask for
>> --ena
On 10/31/2014 03:46 PM, Andres Freund wrote:
On 2014-10-27 09:30:33 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-10-27 12:51:44 +0200, Heikki Linnakangas wrote:
replication/slot.c and replication/logical/snapbuild.c use a CRC on the
physical slot and snapshot files. It uses the same a
On Sat, Nov 1, 2014 at 10:26 AM, Andres Freund
wrote:
> On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
> > On 10/31/2014 03:07 PM, Tom Lane wrote:
> > > I don't care one way or the other about the money type, but I will
> defend
> > > hash indexes, especially seeing that we've already added a p
On 11/1/14, 8:41 AM, Petr Jelinek wrote:
Well this is not BDR specific thing, the idea is that with logical replication,
commit timestamp is not enough for conflict handling, you also need to have
additional info in order to identify some types of conflicts conflicts (local
update vs remote up
On 11/2/14 11:36 AM, Tom Lane wrote:
> Committed patch looks good, but should we also add the stanza we discussed
> in Makefile.global.in concerning defining $(prove) in terms of "missing"
> if we didn't find it? I think the behavior of HEAD when you ask for
> --enable-tap-tests but don't have "pr
On 11/3/14 6:04 AM, Alexey Vasiliev wrote:
> 3. What the patch does in a short paragraph: This patch should add
> option recovery_timeout, which help to control timeout of
> restore_command nonzero status code. Right now default value is 5
> seconds. This is useful, if I using for rest
David Fetter wrote:
> On Mon, Nov 03, 2014 at 01:54:09PM +0100, Michael Banck wrote:
> > As an additional datapoint, Vitesse Data changed the DB schema from
> > NUMERIC to MONEY for their TPCH benchmark for performance reasons: "The
> > modification to data types is easy to understand -- money and
On Mon, Nov 03, 2014 at 01:54:09PM +0100, Michael Banck wrote:
> Am Sonntag, den 02.11.2014, 12:41 -0500 schrieb Tom Lane:
> > BTW, after reflecting a bit more I'm less than convinced that this
> > datatype is completely useless. Even if you prefer to store currency
> > values in numeric columns,
Hi!
Given a transaction started with "BEGIN (REPEATABLE READ |
SERIALIZABLE)", if a concurrent session commits some data before *any*
query within the first transaction, that committed data is seen by the
transaction. This is not what I'd expect. Specifically, the
documentation st
On 11/1/14, 1:45 PM, Andrew Dunstan wrote:
On 11/01/2014 02:34 PM, Andres Freund wrote:
Yeah, if we were trying to duplicate the behavior of indisvalid, there'd
need to be a way to detect the invalid index at plan time and not use it.
But I'm not sure that that's actually an improvement from the
On Mon, Nov 3, 2014 at 1:02 PM, Simon Riggs wrote:
> OK, I think I'm happy with this as a general point.
Cool!
> How will we automatically test this code?
Good question. I can see two possible approaches:
1. We write a test_group_locking harness along the lines of
test_shm_mq and test_decodin
On 3 November 2014 17:00, Robert Haas wrote:
> On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs wrote:
>> The main question is still why any of this is necessary? If we are
>> only acquiring fast path locks in workers, what need is there for any
>> of this? The leader and workers never conflict with e
At 2014-11-03 17:31:37 +, si...@2ndquadrant.com wrote:
>
> Stephen's suggestion allows auditing to be conducted without the
> users/apps being aware it is taking place.
OK, that makes sense. I'm working on a revised patch that does things
this way, and will post it in a few days.
-- Abhijit
On 14 October 2014 20:33, Abhijit Menon-Sen wrote:
> At 2014-10-14 20:09:50 +0100, si...@2ndquadrant.com wrote:
>>
>> I think that's a good idea.
>>
>> We could have pg_audit.roles = 'audit1, audit2'
>
> Yes, it's a neat idea, and we could certainly do that. But why is it any
> better than "ALTER
Hi all,
we experienced what seems to be a bug in the COPY TO implementation. When a
table is being rewritten by an ALTER TABLE statement, a parallel COPY TO
results in an empty result.
Consider the following table data:
CREATE TABLE test (id INTEGER NOT NULL, PRIMARY KEY (id));
INSERT INTO t
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > That said, I don't feel very strongly about that position, so if you and
> > Robert (and others on the thread) agree that's the right approach then
> > I'll see about getting it done.
Thanks for trying to make progress on this
On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs wrote:
> The main question is still why any of this is necessary? If we are
> only acquiring fast path locks in workers, what need is there for any
> of this? The leader and workers never conflict with each other, so why
> would they ever wait for each o
All,
> That said, I don't feel very strongly about that position, so if you and
> Robert (and others on the thread) agree that's the right approach then
> I'll see about getting it done.
We haven't reached consensus on this one yet and I didn't want it to fall
too far off the radar.
Here is wh
On Mon, Nov 3, 2014 at 10:18 AM, Greg Stark wrote:
> On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas wrote:
>> 1. Any non-trivial piece of PostgreSQL code is likely to contain
>> syscache lookups.
>> 2. Syscache lookups had better work in parallel workers, or they'll be
>> all but useless.
>
> I've b
Greg Stark writes:
> On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas wrote:
>> 2. Syscache lookups had better work in parallel workers, or they'll be
>> all but useless.
> I've been using parallel sorts and index builds in my mental model of
> how this will be used. I note that sorts go out of their
On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas wrote:
> 1. Any non-trivial piece of PostgreSQL code is likely to contain
> syscache lookups.
> 2. Syscache lookups had better work in parallel workers, or they'll be
> all but useless.
I've been using parallel sorts and index builds in my mental model
On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
> Is the following summary correct:
> - the network protocol supports pipelinings
Yes.
All you have to do is *not* send a Sync message and be aware that the
server will discard all input until the next Sync, so pipelining +
autocommit doesn't make a t
On 11/01/2014 10:04 PM, Mikko Tiihonen wrote:
> Hi,
>
> I created a proof of concecpt patch for postgresql JDBC driver that allows
> the caller to do pipelining of requests within a transaction. The pipelining
> here means same as for HTTP: the client can send the next execution already
> befor
Am Sonntag, den 02.11.2014, 12:41 -0500 schrieb Tom Lane:
> BTW, after reflecting a bit more I'm less than convinced that this
> datatype is completely useless. Even if you prefer to store currency
> values in numeric columns, casting to or from money provides a way to
> accept or emit values in w
On Mon, Nov 3, 2014 at 3:12 AM, Rushabh Lathia
wrote:
>
> Patch looks good, assigning to committer.
>
Thanks for your review!
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.c
Hello everyone.
* Project name: Add recovery_timeout option to control timeout of
restore_command nonzero status code
* Uniquely identifiable file name, so we can tell difference between your v1
and v24: 0001-add-recovery_timeout-to-controll-timeout-between-res.patch
* What the patch does
75 matches
Mail list logo
