On 12/10/2014 03:04 AM, Alvaro Herrera wrote:
Alex Shulgin wrote:
The 2PC part requires extending bool flag to fit the trunc flag, is this
approach sane? Given that 2PC transaction should survive server
restart, it's reasonable to expect it to also survive the upgrade, so I
see no clean way
On Tue, Dec 9, 2014 at 2:15 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Dec 8, 2014 at 3:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 8 December 2014 at 11:46, Michael Paquier michael.paqu...@gmail.com
wrote:
I don't really like those new names, but I'd prefer
On Tue, Dec 9, 2014 at 05:40:35PM -0500, Stephen Frost wrote:
I thought the idea was to backpatch documentation saying it's a good idea
to change this value to x because of y. Not actually referring to the
upcoming change directly. And I still think that part is a good idea, as it
helps
On Wed, Dec 10, 2014 at 10:32:42AM +0200, Heikki Linnakangas wrote:
I don't think we need to have 2PC files survive a pg_upgrade. It seems
perfectly okay to remove them from the new cluster at some appropriate
time, *if* they are copied from the old cluster at all (I don't think
they should
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Dec 9, 2014 at 05:40:35PM -0500, Stephen Frost wrote:
I thought the idea was to backpatch documentation saying it's a good idea
to change this value to x because of y. Not actually referring to the
upcoming change directly. And I still
On 12/09/2014 10:35 PM, Robert Haas wrote:
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't immediately see the problem either, but I have to say that
grovelling through all the
On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Andrew Dunstan wrote:
I seriously doubt it, although I could be wrong. Unless someone can show a
significant performance gain from using physical order, which would be a bit
of
Tomas Vondra t...@fuzzy.cz wrote:
back when we were discussing the hashjoin patches (now committed),
Robert proposed that maybe it'd be a good idea to sometimes increase the
number of tuples per bucket instead of batching.
That is, while initially sizing the hash table - if the hash table
Bruce Momjian br...@momjian.us writes:
On Wed, Dec 10, 2014 at 10:32:42AM +0200, Heikki Linnakangas wrote:
I don't think we need to have 2PC files survive a pg_upgrade. It seems
perfectly okay to remove them from the new cluster at some appropriate
time, *if* they are copied from the old
What I would suggest is instrument the backend with getrusage() at
startup and shutdown and have it print the difference in user time and
system time. Then, run tests for a fixed number of transactions and
see how the total CPU usage for the run differs.
Folllowing are the numbers obtained on
Amit Langote wrote:
On Wed, Dec 10, 2014 at 12:46 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Dec 9, 2014 at 7:21 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
FWIW in my original proposal I was rejecting some things that after
further consideration turn out to be
On Wed, Dec 10, 2014 at 07:40:46PM +0530, Rahila Syed wrote:
The tests ran for around 30 mins.Manual checkpoint was run before each test.
Compression WAL generated %compression Latency-avg CPU usage
(seconds) TPS Latency
stddev
Robert Haas wrote:
On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Andrew Dunstan wrote:
I seriously doubt it, although I could be wrong. Unless someone can show a
significant performance gain from using physical order,
Hi,
Am 04.09.2014 um 17:50 schrieb Jehan-Guillaume de Rorthais j...@dalibo.com:
Since few months, we occasionally see .ready files appearing on some slave
instances from various context. The two I have in mind are under 9.2.x. […]
So it seems for some reasons, these old WALs were forgotten by
On Wed, Dec 10, 2014 at 12:10 PM, Rahila Syed rahilasye...@gmail.com
wrote:
What I would suggest is instrument the backend with getrusage() at
startup and shutdown and have it print the difference in user time and
system time. Then, run tests for a fixed number of transactions and
see how
On Wed, Dec 10, 2014 at 7:34 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
1. I don't really see why resource owners shouldn't be traversed like
that. They are clearly intended to form a hierarchy, and there's
existing code that recurses through the hierarchy from a given level
On 10/12/14 04:26, Michael Paquier wrote:
On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Yeah, it was raised. I don't think it was really addressed. There was
lengthy discussion on whether to include LSN, node id, and/or some other
information, but there was
On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
3. A binary heap would be a better data structure to buffer the rechecked
values. A Red-Black tree allows random insertions and deletions, but in
this case you need to insert arbitrary values but only remove the minimum
item. That's exactly what
On Wed, Dec 10, 2014 at 9:25 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
FWIW I have no intention to add options for physical/logical ordering
anywhere. All users will see is that tables will follow the same
(logical) order everywhere.
Just to be clear, I wasn't in any way attending to
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
To the extent that I have any concern about the patch at this point,
it's around stability. I would awfully rather see something like this
get committed at the beginning of a development cycle than the end.
I tend to agree with this;
On Wed, Dec 10, 2014 at 9:49 AM, Robert Haas robertmh...@gmail.com wrote:
I guess this bears some further thought. I certainly don't like the
fact that this makes the whole system crap out at a lower number of
subtransactions than presently. The actual performance numbers don't
bother me
On Wed, Dec 10, 2014 at 11:22 AM, Stephen Frost sfr...@snowman.net wrote:
I'm not quite sure that I see how that's relevant. Bugs will happen,
unfortunately, no matter how much review is done of a given patch. That
isn't to say that we shouldn't do any review, but it's a trade-off.
This
On 2014-12-10 12:06:11 -0500, Robert Haas wrote:
Ultimately, I think this is mostly going to be a question of what
Alvaro feels comfortable with; he's presumably going to have a better
sense of where and to what extent there might be bugs lurking than any
of the rest of us. But the point is
On 12/10/2014 06:56 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 9:49 AM, Robert Haas robertmh...@gmail.com wrote:
I guess this bears some further thought. I certainly don't like the
fact that this makes the whole system crap out at a lower number of
subtransactions than presently. The
On Wed, Dec 10, 2014 at 9:22 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
The problem with naming partitions is that the user has to pick names
for every partition, which is tedious and doesn't provide any
significant benefit. The input I had from users of other partitioning
systems was
On Mon, Dec 8, 2014 at 5:05 PM, Jim Nasby jim.na...@bluetreble.com wrote:
Agreed, but it's possible to keep a block/CTID interface while doing
something different on the disk.
Objection: hand-waving.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Dec 8, 2014 at 10:59 PM, Amit Kapila amit.kapil...@gmail.com wrote:
Yeah and also how would user specify the values, as an example
assume that table is partitioned on monthly_salary, so partition
definition would look:
PARTITION BY LIST(monthly_salary)
(
PARTITION
On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Clever. Could we use that method in ResourceOwnerReleaseInternal and
ResourceOwnerDelete, too? Might be best to have a
ResourceOwnerWalk(resowner, callback) function for walking all resource
owners in a tree,
Andrew Gierth and...@tao11.riddles.org.uk writes:
And here is that recut patch set.
I started looking over this patch, but eventually decided that it needs
more work to be committable than I'm prepared to put in right now.
My single biggest complaint is about the introduction of struct
Thomas Reiss thomas.re...@dalibo.com wrote:
postgres=# create table test1 (a text);
CREATE TABLE
postgres=# insert into test1 select generate_series(1,10);
INSERT 0 10
postgres=# create index idx1 on test1(a);
CREATE INDEX
postgres=# analyze test1 ;
ANALYZE;
postgres=# explain
On 12/9/14 5:40 PM, Stephen Frost wrote:
I agree with this but I don't really see why we wouldn't say hey, this
is going to change in 9.5.
Well, for one thing, we don't even know if it's going to be called 9.5. ;-)
And there is always a chance for a technical reason popping up that we
might
On 12/10/2014 08:35 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Clever. Could we use that method in ResourceOwnerReleaseInternal and
ResourceOwnerDelete, too? Might be best to have a
ResourceOwnerWalk(resowner, callback) function
On Wed, Dec 10, 2014 at 1:50 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
3. A binary heap would be a better data structure to buffer the rechecked
values. A Red-Black tree allows random insertions and deletions, but in
this case
On Friday, December 05, 2014 12:22:38 PM Heikki Linnakangas wrote:
Oh, that's what the PQgetLastQuery/PQgetNextQuery functions work! I
didn't understand that before. I'd suggest renaming them to something
like PQgetSentQuery() and PQgetResultQuery(). The first/last/next names
made me think
On 12/10/2014 10:59 PM, Arthur Silva wrote:
It may be better to replace the lib/binaryheap altogether as it offers
comparable/better performance.
It's not always better. A binary heap is more memory-efficient, for
starters.
There are only two uses of lib/binaryheap: reorderbuffer.c and
Hi all,
A little typo in vacuumdb tests.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Timbira: http://www.timbira.com.br
Blog: http://fabriziomello.github.io
Linkedin: http://br.linkedin.com/in/fabriziomello
Twitter: http://twitter.com/fabriziomello
Github:
Kevin Grittner kgri...@ymail.com writes:
It's kinda hard for me to visualize where it makes sense to define
the original table column as the bare type but use a domain when
referencing it in the view.
As far as that goes, I think the OP was unhappy about the performance
of the
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
It's kinda hard for me to visualize where it makes sense to define
the original table column as the bare type but use a domain when
referencing it in the view.
As far as that goes, I think the OP was unhappy about
Hello,
Attached is a basic implementation of TABLESAMPLE clause. It's SQL
standard clause and couple of people tried to submit it before so I
think I don't need to explain in length what it does - basically returns
random sample of a table using a specified sampling method.
I implemented
On 11/12/14 00:24, Petr Jelinek wrote:
Hello,
Attached is a basic implementation of TABLESAMPLE clause. It's SQL
standard clause and couple of people tried to submit it before so I
think I don't need to explain in length what it does - basically returns
random sample of a table using a
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
As far as that goes, I think the OP was unhappy about the performance
of the information_schema views, which in our implementation do exactly
that so that the exposed types of the view columns conform to the SQL
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Care to code it up?
Here you are.
That was quick.
You need to add a semicolon to the end of line 20 in pairingheap.c.
I wonder what the worst case for this is. I tried it on your
destruction test case from
Michael Paquier michael.paqu...@gmail.com writes:
On Tue, Dec 9, 2014 at 11:11 AM, Mark Dilger m...@port25.com wrote:
Perhaps the code really meant to say:
reserveFromBuffer(buffer, VARHDRSZ)
Good catch! The code is indeed incorrect. Attached is a one-line patch
addressing that, I guess
From: Robert Haas [mailto:robertmh...@gmail.com]
On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund
and...@2ndquadrant.com wrote:
I don't think that's mutually exclusive with the idea of
partitions-as-tables. I mean, you can add code to the ALTER TABLE
path that says if
* Andres Freund (and...@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different ballgame than if we
try to go back to september.
On Wed, Dec 10, 2014 at 7:25 PM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
In heap_create(), do we create storage for a top level partitioned table
(say, RELKIND_PARTITIONED_TABLE)? How about a partition that is further
sub-partitioned? We might allocate storage for a partition at
On 12/10/14 4:55 PM, Fabrízio de Royes Mello wrote:
Hi all,
A little typo in vacuumdb tests.
Fixed, thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Dec 6, 2014 at 10:08 PM, Tomas Vondra t...@fuzzy.cz wrote:
select a.i, b.i from a join b on (a.i = b.i);
I think the concern is that the inner side might be something more
elaborate than a plain table scan, like an aggregate or join. I might
be all wet, but my impression is that you
On Mon, Dec 08, 2014 at 02:23:39AM +0100, Petr Jelinek wrote:
On 08/12/14 00:56, Noah Misch wrote:
The commit_ts test suite gives me the attached diff on a 32-bit MinGW build
running on 64-bit Windows Server 2003. I have not checked other Windows
configurations; the suite does pass on
On Mon, Dec 8, 2014 at 2:51 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-10-30 07:55:08 -0400, Robert Haas wrote:
On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund and...@2ndquadrant.com
wrote:
But if it is, then how about
adding a flag that is 4 bytes wide or less alongside
On Tue, Dec 9, 2014 at 3:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
Feedback I am receiving is that the API is unusable. That could be
because it is impenetrable, or because it is unusable. I'm not sure it
matters which.
It would be nice to here what someone is trying to use it for and
On 12/10/2014 05:14 PM, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different
On 12/09/2014 09:11 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Question on COPY, though: there's reasons why people would want COPY to
dump in either physical or logical order. If you're doing COPY to
create CSV files for output, then you want the columns in logical order.
If
Hi Ashutosh,
Thanks for the review!
(2014/12/10 14:47), Ashutosh Bapat wrote:
We haven't heard anything from Horiguchi-san and Hanada-san for almost a
week. So, I am fine marking it as ready for committer. What do you say?
ISTM that both of them are not against us, so let's ask for the
Hi,
A customer recently reported getting backup_label contains data
inconsistent with control file after taking a basebackup from a standby
and starting it with a typo in primary_conninfo.
When starting postgres from a basebackup StartupXLOG() has the follow
code to deal with backup labels:
On Thu, Dec 11, 2014 at 7:44 AM, Mark Dilger m...@port25.com wrote:
At line 1787 of outfuncs.c, the line:
WRITE_UINT_FIELD(reltablespace)
should probably say
WRITE_OID_FIELD(reltablespace)
since that variable is of type Oid, not uint32.
Granted, these two macros are
On Wed, Dec 10, 2014 at 7:52 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Amit Langote wrote:
On Wed, Dec 10, 2014 at 12:46 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Dec 9, 2014 at 7:21 PM, Alvaro Herrera
alvhe...@2ndquadrant.com
wrote:
FWIW in my original
On Wed, Dec 10, 2014 at 11:51 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 8, 2014 at 10:59 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
Yeah and also how would user specify the values, as an example
assume that table is partitioned on monthly_salary, so partition
definition
Peter Eisentraut pete...@gmx.net writes:
initdb currently does
PG_CMD_PUTS(ANALYZE;\nVACUUM FULL;\nVACUUM FREEZE;\n);
FREEZE is now part of FULL, so this seems redundant. Also, ANALYZE can
be run as part of VACUUM. So this could be
PG_CMD_PUTS(VACUUM FULL ANALYZE;\n);
Merging the
Josh Berkus j...@agliodbs.com writes:
On 12/10/2014 05:14 PM, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one
I marked this as ready for committer.
On Thu, Dec 11, 2014 at 8:39 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
Hi Ashutosh,
Thanks for the review!
(2014/12/10 14:47), Ashutosh Bapat wrote:
We haven't heard anything from Horiguchi-san and Hanada-san for almost a
week. So, I am
On Mon, Dec 8, 2014 at 8:16 PM, Peter Geoghegan p...@heroku.com wrote:
Attached revision, v1.6, slightly tweaks the ordering of per-statement
trigger execution.
Right now, there is no way for a before row insert/update trigger to
determine whether it was called as part of an INSERT ... ON
On 12/10/2014 09:35 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 12/10/2014 05:14 PM, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to
I have heard repeated concerns about the commitfest process in the past
few months. The fact we have been in a continual commitfest since
August also is concerning.
I think we are reaching the limits on how much we can do with our
existing commitfest structure, and it might be time to consider
On 12/10/2014 10:35 PM, Bruce Momjian wrote:
I have heard repeated concerns about the commitfest process in the past
few months. The fact we have been in a continual commitfest since
August also is concerning.
I think we are reaching the limits on how much we can do with our
existing
I am sorry but I can't understand the above results due to wrapping.
Are you saying compression was twice as slow?
CPU usage at user level (in seconds) for compression set 'on' is 562 secs
while that for compression set 'off' is 354 secs. As per the readings, it
takes little less than double
66 matches
Mail list logo
