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 of
On Tue, Dec 9, 2014 at 2:15 PM, Amit Kapila wrote:
> On Mon, Dec 8, 2014 at 3:17 PM, Simon Riggs wrote:
> >
> > On 8 December 2014 at 11:46, Michael Paquier
> wrote:
> > > I don't really like those new names, but I'd prefer
> > > wal_compression_level if we go down that road with 'none' as defa
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
>
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 s
* 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. An
On 12/09/2014 10:35 PM, Robert Haas wrote:
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas wrote:
On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
wrote:
I don't immediately see the problem either, but I have to say that
grovelling through all the resource owners seems ugly anyway. Resource
own
On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane wrote:
> Alvaro Herrera 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 a surprise to me, I would just
Tomas Vondra 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 with
> enou
Bruce Momjian 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 cluster at
>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 wrote:
> > On Tue, Dec 9, 2014 at 7:21 PM, Alvaro Herrera
> > wrote:
> >> FWIW in my original proposal I was rejecting some things that after
> >> further consideration turn out to be possible to allow; for instance
> >> direct
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
> std
Robert Haas wrote:
> On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane wrote:
> > Alvaro Herrera 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
>
Hi,
Am 04.09.2014 um 17:50 schrieb Jehan-Guillaume de Rorthais :
> 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 the
> resta
On Wed, Dec 10, 2014 at 12:10 PM, Rahila Syed
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 the total CPU usa
On Wed, Dec 10, 2014 at 7:34 AM, Heikki Linnakangas
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
>>> downward. What's
On 10/12/14 04:26, Michael Paquier wrote:
On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
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 no discussion on:
* What
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 wh
On Wed, Dec 10, 2014 at 9:25 AM, Alvaro Herrera
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 say that the patch
ha
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 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 very much; I'm comfor
On Wed, Dec 10, 2014 at 11:22 AM, Stephen Frost 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 change, at least, s
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 i
On 12/10/2014 06:56 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 9:49 AM, Robert Haas 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
On Wed, Dec 10, 2014 at 9:22 AM, Alvaro Herrera
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 that they very much
On Mon, Dec 8, 2014 at 5:05 PM, Jim Nasby 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
--
Sent via pgsql-hack
On Mon, Dec 8, 2014 at 10:59 PM, Amit Kapila 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 salary_less_than_thousand VALUES(30
On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
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, instead of one for wa
Andrew Gierth 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
GroupedVar. If we stick with that,
Thomas Reiss 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 select * from tes
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
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
o
On Wed, Dec 10, 2014 at 1:50 PM, Heikki Linnakangas 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 you need to in
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 merge
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 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 information_schema views, which
Tom Lane wrote:
> Kevin Grittner 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 inf
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 b
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 specifi
Kevin Grittner writes:
> Tom Lane 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
>> standard, even though the underl
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
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 before and it doesn't
Michael Paquier writes:
> On Tue, Dec 9, 2014 at 11:11 AM, Mark Dilger 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 someone is going to pick up that soon
> From: Robert Haas [mailto:robertmh...@gmail.com]
> On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund
> 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 (i_am_not_the_partitioning_root
* 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
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 some point and
> then later c
* Peter Eisentraut (pete...@gmx.net) wrote:
> 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. ;-)
Now that is certainly
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");
There has been some concerns about time spent in init
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
> "Tom" == Tom Lane writes:
More comment on this later, but I want to highlight these specific
points since we need clear answers here to avoid wasting unnecessary
time and effort:
Tom> I've not spent any real effort looking at gsp2.patch yet, but it
Tom> seems even worse off comment-wise:
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 interchangeable,
but they won't be if we ever move to 64-bit Oids.
mark
--
S
On Wed, Dec 10, 2014 at 8:50 PM, Peter Eisentraut wrote:
> In an unrelated change, use VACUUM FULL; VACUUM FREEZE; rather than
> a single VACUUM FULL FREEZE command, to respond to my worries of a
> couple days ago about the reliability of doing this in one go.
>
> That was a long time
On Sat, Dec 6, 2014 at 10:08 PM, Tomas Vondra 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 can make res
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 G
On Mon, Dec 8, 2014 at 2:51 PM, Andres Freund wrote:
> On 2014-10-30 07:55:08 -0400, Robert Haas wrote:
>> On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund
>> wrote:
>> >> But if it is, then how about
>> >> adding a flag that is 4 bytes wide or less alongside bgwriterLatch,
>> >> and just checking
On Tue, Dec 9, 2014 at 3:24 AM, Simon Riggs 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 what
problems that pe
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 dif
On 12/09/2014 09:11 PM, Tom Lane wrote:
> Josh Berkus 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 you're d
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
com
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 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 interchang
On Wed, Dec 10, 2014 at 7:52 PM, Alvaro Herrera
wrote:
>
> Amit Langote wrote:
>
> > On Wed, Dec 10, 2014 at 12:46 PM, Amit Kapila
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
On Wed, Dec 10, 2014 at 11:51 PM, Robert Haas wrote:
>
> On Mon, Dec 8, 2014 at 10:59 PM, Amit Kapila
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
Peter Eisentraut 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 ANALYZE
Josh Berkus 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 year from
I marked this as ready for committer.
On Thu, Dec 11, 2014 at 8:39 AM, Etsuro Fujita
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 fine marking it as "
On Mon, Dec 8, 2014 at 8:16 PM, Peter Geoghegan 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 CONFLICT
UPDATE or
On 12/10/2014 09:35 PM, Tom Lane wrote:
> Josh Berkus 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 rele
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 ch
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 C
71 matches
Mail list logo
