Hi,
While playing with LATERAL along with some aggregates in sub-query, I have
observed somewhat unusual behavior.
Consider following steps:
create table tab1(c1 int, c2 int);
insert into tab1 select id, 1 from generate_series(1, 3) id;
create function sum_tab1(extra int) returns setof bigint
On Wed, Aug 24, 2016 at 2:04 AM, Alvaro Herrera
wrote:
> Claudio Freire wrote:
>
>> After looking at it from a birdseye view, I agree it's conceptually
>> complex (reading HeapTupleSatisfiesSelf already makes one dizzy).
>>
>> But other than that, the implementation
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
wrote:
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
wrote:
Can
On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes wrote:
> Hi Amit,
>
> Thanks for working on this.
>
> When building with --enable-cassert, I get compiler warning:
>
> hash.c: In function 'hashbucketcleanup':
> hash.c:722: warning: 'new_bucket' may be used uninitialized in this
Claudio Freire wrote:
> After looking at it from a birdseye view, I agree it's conceptually
> complex (reading HeapTupleSatisfiesSelf already makes one dizzy).
>
> But other than that, the implementation seems rather simple. It seems
> to me, if one figures out that it is safe to do so
On 24/08/16 16:33, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood
wrote:
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
wrote:
Can you get the call stacks?
For every stuck
On Tue, Aug 23, 2016 at 8:50 PM, Michael Paquier
wrote:
> On Tue, Aug 23, 2016 at 6:10 PM, Simon Riggs wrote:
>> On 23 August 2016 at 09:39, Petr Jelinek wrote:
>>
>>> Looks very reasonable to me (both patches). Thanks for
On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood
wrote:
> On 24/08/16 15:36, Amit Kapila wrote:
>>
>> On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
>> wrote:
>>>
>>
>> Can you get the call stacks?
>>
>
> For every stuck backend? (just
On 24/08/16 15:36, Amit Kapila wrote:
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
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 index
On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood
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 index patch [2].
>>>
On 2016/08/10 5:19, Robert Haas wrote:
On Mon, Aug 8, 2016 at 12:22 AM, Etsuro Fujita
wrote:
One thing we need to do to leave that as is would be to fix a bug that I
pointed out upthred. Let me explain about that again. The EXPLAIN command
selects relation
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] -
Andres Freund writes:
> On 2016-08-23 19:54:39 -0700, Jeff Janes wrote:
>> commit ed0097e4f9e6b1 has introduced two compiler warnings:
> That's probably when compiling without assertions, right? rd_index is
> only read from within Assert()'s Probably needs a
>
On 2016-08-23 19:54:39 -0700, Jeff Janes wrote:
> Sorry for starting a new thread, I can't find the correct one to reply to.
>
> Using: gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE
> Linux)
>
> commit ed0097e4f9e6b1 has introduced two compiler warnings:
>
> gistutil.c: In
Sorry for starting a new thread, I can't find the correct one to reply to.
Using: gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)
commit ed0097e4f9e6b1 has introduced two compiler warnings:
gistutil.c: In function 'gistproperty':
gistutil.c:855:16: warning: variable
From: Peter Geoghegan [mailto:p...@heroku.com]
> On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote:
> >> [Windows]
> >> #clients onoff
> >> 12 29793 38169
> >> 24 31587 87237
> >> 48 32588 83335
> >> 96 34261 67668
> >
> > This ranges from a 28% to a
Andres Freund writes:
> On 2016-08-23 17:22:03 -0400, Tom Lane wrote:
>> I can't immediately think of a reason for this. In everyday
>> updates you could theorize about effects like autovacuum
>> asynchonously updating the FSM, but surely the FSM should have no
>> impact on
On Tue, Aug 23, 2016 at 9:12 PM, Tomas Vondra
wrote:
> On 08/24/2016 12:38 AM, Claudio Freire wrote:
>>
>> On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra
>> wrote:
>
> Could someone please explain how the unlogged tables are
On Wed, Aug 24, 2016 at 10:07 AM, Gavin Flower <
gavinflo...@archidevsys.co.nz> wrote:
> On 24/08/16 12:02, neha khatri wrote:
>
>> >Andres Freund > writes:
>> >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote:
>> >> On Sat, Aug 20, 2016 at 11:17
On Wed, Aug 24, 2016 at 9:55 AM, Alvaro Herrera
wrote:
> Ryan Murphy wrote:
>> Thanks for committing it Tom! Thank you all for your help.
>>
>> I really like the Postgres project! If there's anything that especially
>> needs worked on let me know, I'd love to help.
>
>
On Tue, Aug 23, 2016 at 8:50 PM, Greg Stark wrote:
> On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev
> wrote:
>> Frankly I have much more faith in Tom's idea of using virtual part of the
>> catalog for all temporary tables, i.e turning all temporary
Ryan Murphy wrote:
> Thanks for committing it Tom! Thank you all for your help.
>
> I really like the Postgres project! If there's anything that especially
> needs worked on let me know, I'd love to help.
https://wiki.postgresql.org/wiki/Todo
--
Álvaro Herrera
On 08/24/2016 12:38 AM, Claudio Freire wrote:
On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra
wrote:
Could someone please explain how the unlogged tables are supposed to fix
the
catalog bloat problem, as stated in the initial patch submission? We'd
still
need to
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 24/08/16 12:02, neha khatri wrote:
>Andres Freund > writes:
>> On 2016-08-22 13:54:43 -0400, Robert Haas wrote:
>> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane > wrote:
I'm inclined to suggest
On Wed, Aug 24, 2016 at 5:34 AM, Martín Marqués wrote:
> Hi,
>
> 2016-08-23 16:46 GMT-03:00 Martín Marqués :
>>
>> I will add tests for sequence and functions as you mention and test again.
>>
>> Then I'll check if other tests should be added as
>Andres Freund writes:
>> On 2016-08-22 13:54:43 -0400, Robert Haas wrote:
>> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote:
I'm inclined to suggest you forget this approach and propose a single
counter for "SQL commands executed", which
On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev
wrote:
> Frankly I have much more faith in Tom's idea of using virtual part of the
> catalog for all temporary tables, i.e turning all temporary tables into
> "fast" temporary tables. Instead of introducing a new type
On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra
wrote:
>>> Could someone please explain how the unlogged tables are supposed to fix
>>> the
>>> catalog bloat problem, as stated in the initial patch submission? We'd
>>> still
>>> need to insert/delete the catalog rows
On 2016-08-23 19:33:33 -0300, Claudio Freire wrote:
> On Tue, Aug 23, 2016 at 7:20 PM, Andres Freund wrote:
> >> Wouldn't more aggressive vacuuming of catalog tables fix the bloat?
> >
> > Not really in my experience, at least not without more drastic vacuum
> > changes. The
On Tue, Aug 23, 2016 at 7:20 PM, Andres Freund wrote:
>> Wouldn't more aggressive vacuuming of catalog tables fix the bloat?
>
> Not really in my experience, at least not without more drastic vacuum
> changes. The issue is that if you have a single "long running"
> transaction
On 08/24/2016 12:18 AM, Claudio Freire wrote:
On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
wrote:
On 08/22/2016 10:32 PM, Robert Haas wrote:
...
1. The number of tables for which we would need to add a duplicate,
unlogged table is formidable. You need
On 2016-08-23 19:18:04 -0300, Claudio Freire wrote:
> On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
> wrote:
> > Could someone please explain how the unlogged tables are supposed to fix the
> > catalog bloat problem, as stated in the initial patch submission? We'd
On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
wrote:
> On 08/22/2016 10:32 PM, Robert Haas wrote:
>>
>>
>> ...
>>
>> 1. The number of tables for which we would need to add a duplicate,
>> unlogged table is formidable. You need pg_attribute, pg_attrdef,
>>
On 08/22/2016 10:32 PM, Robert Haas wrote:
...
1. The number of tables for which we would need to add a duplicate,
unlogged table is formidable. You need pg_attribute, pg_attrdef,
pg_constraint, pg_description, pg_type, pg_trigger, pg_rewrite, etc.
And the backend changes needed so that we
On Tue, Aug 23, 2016 at 10:50 PM, Amit Kapila wrote:
> On Tue, Aug 23, 2016 at 6:11 PM, Michael Paquier
> wrote:
>> On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada
>> wrote:
>>> As for PoC, I implemented parallel
On 8/23/16 3:34 PM, Martín Marqués wrote:
I found quite some other objects we should be checking as well, but
this will add some duplication to the tests, as I'd just copy (with
minor changes) what's in src/bin/pg_dump/t/002_pg_dump.pl
I can't think of a way to avoid this duplication, not that
On 2016-08-23 17:22:03 -0400, Tom Lane wrote:
> I happened to notice, while experimenting with the data set used
> in the SPGIST-for-inet thread, that loading the supplied pg_dump
> script and immediately dumping it does not reproduce the row order
> appearing in the original dump script. I
Greetings,
Attached is an rebased and updated patch to remove the explicit
superuser() checks from the contrib extension pgstattuple, in favor of
using the GRANT system to control access, and give the admin flexibility
to GRANT access to this function without having to write wrapper
functions,
I happened to notice, while experimenting with the data set used
in the SPGIST-for-inet thread, that loading the supplied pg_dump
script and immediately dumping it does not reproduce the row order
appearing in the original dump script. I thought maybe this had
something to do with the
Hi Amit,
Thanks for working on this.
When building with --enable-cassert, I get compiler warning:
hash.c: In function 'hashbucketcleanup':
hash.c:722: warning: 'new_bucket' may be used uninitialized in this function
After an intentionally created crash, I get an Assert triggering:
TRAP:
On Tue, Aug 23, 2016 at 01:58:02PM -0700, Peter Geoghegan wrote:
> On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote:
> >> [Windows]
> >> #clients onoff
> >> 12 29793 38169
> >> 24 31587 87237
> >> 48 32588 83335
> >> 96 34261 67668
> >
> > This ranges
On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote:
>> [Windows]
>> #clients onoff
>> 12 29793 38169
>> 24 31587 87237
>> 48 32588 83335
>> 96 34261 67668
>
> This ranges from a 28% to a 97% speed improvement on Windows! Those are
> not typos! This is
On Tue, Aug 16, 2016 at 11:53:25AM +0200, Magnus Hagander wrote:
> On Fri, Aug 5, 2016 at 12:25 PM, Tsunakawa, Takayuki <
> tsunakawa.ta...@jp.fujitsu.com> wrote:
>
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > Yeah, I think I agree. It would be bad to disable it by default on
>
Hi,
I've tried your indexonlypatch5.patch against REL9_6_BETA3.
Here are some results.
TL;DR:
1) <> does not support index-only
scan for index (type, upper(vc) varchar_pattern_ops).
3) <<(... where type=42 offset 0) where upper_vc like '%ABC%'>> does
trigger index-only scan. IOS reduces number
Hi,
2016-08-23 16:46 GMT-03:00 Martín Marqués :
>
> I will add tests for sequence and functions as you mention and test again.
>
> Then I'll check if other tests should be added as well.
I found quite some other objects we should be checking as well, but
this will add
Hi Michael,
2016-08-23 5:02 GMT-03:00 Michael Paquier :
> On Sat, Aug 13, 2016 at 6:58 AM, Martín Marqués
> wrote:
>> I believe the fix will be simple after the back and forth mails with
>> Michael, Stephen and Tom. I will work on that later,
Robert Haas wrote:
> On Tue, Aug 23, 2016 at 10:10 AM, Antonin Houska wrote:
> CLUSTER preserves xmin/xmax when rewriting, but ALTER TABLE does not.
Indeed, CLUSTER was the command I picked for my experiments. I didn't expect
such a subtle difference.
I've pushed this patch with mostly (not entirely) cosmetic adjustments.
I still think it'd be worth looking into why the produced index is larger
than the GiST equivalent, and for that matter exactly why the GiST
equivalent is so much slower to search.
regards, tom lane
On Tue, Aug 23, 2016 at 12:59 PM, Craig Ringer wrote:
> Also fine by me. You're right, keep it simple. It means the potential set of
> values isn't discoverable the same way, but ... meh. Using it usefully means
> reading the docs anyway.
>
> The remaining 2 patches of
Hi
2016-08-19 10:58 GMT+02:00 Pavel Stehule :
> Hi
>
> I am sending implementation of xmltable function. The code should to have
> near to final quality and it is available for testing.
>
> I invite any help with documentation and testing.
>
new update - the work with
On 2016-08-17 17:41:28 -0700, Andres Freund wrote:
> a) Allow to avoid using a tuplestore for SRF_PERCALL SRFs in ROWS FROM -
>otherwise our performance would regress noticeably in some cases.
To demonstrate the problem:
master:
=# COPY (SELECT generate_series(1, 5000)) TO '/dev/null';
On Mon, Aug 22, 2016 at 10:04 AM, Amit Kapila wrote:
> On Mon, Aug 22, 2016 at 6:06 PM, Thomas Munro
> wrote:
>> On Tue, Aug 23, 2016 at 12:07 AM, Amit Kapila
>> wrote:
>>> + int control_slot = -1;
>>> ...
>>> +
On Tue, Aug 23, 2016 at 2:33 PM, Bruce Momjian wrote:
> Well, the patch was updated several times, and the final version was not
> objected to until you objected.
It is not clear what you mean by "the final version", because you
posted two different final versions. I don't see
Just a note from me - I also agree this thread evolved (or rather devolved)
in a rather unproductive and strange way.
One important note that came out, though, is that adding a new client
message does have a backwards compatibility issue - intelligent proxies
such as pgbouncer/pgpool will
Bruce Momjian wrote:
> On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote:
> > > That's why I was asking you to comment on the final patch, which I am
> > > planning to apply to PG 10 soon.
> >
> > Oh, OK. I
On Tue, Aug 23, 2016 at 11:35:35AM -0700, Andres Freund wrote:
> On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote:
> > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote:
> > > > That's why I was asking you to
On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote:
> On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote:
> > > That's why I was asking you to comment on the final patch, which I am
> > > planning to apply to PG
On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote:
> > That's why I was asking you to comment on the final patch, which I am
> > planning to apply to PG 10 soon.
>
> Oh, OK. I didn't understand that that was
On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote:
> That's why I was asking you to comment on the final patch, which I am
> planning to apply to PG 10 soon.
Oh, OK. I didn't understand that that was what you are asking. I
don't find either of your proposed final patches
On Tue, Aug 23, 2016 at 11:50 AM, Andres Freund wrote:
> On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote:
>> On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner wrote:
>> > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer
>> > wrote:
>>
On Tue, Aug 23, 2016 at 01:53:25PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian wrote:
> >> I have already read the entire thread, and replied only after reading
> >> all messages.
> >
> > Well, what are you replying to then?
>
> Your original
On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian wrote:
>> I have already read the entire thread, and replied only after reading
>> all messages.
>
> Well, what are you replying to then?
Your original message. I'm arguing that we should not change the
behavior, as you proposed
On Tue, Aug 23, 2016 at 01:45:44PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian wrote:
> > On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
> >> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote:
> >> > and the
On Thu, Jul 28, 2016 at 9:12 PM, Kyotaro HORIGUCHI
wrote:
> Looking into pqcomm.c, I noticed that the prototype of
> socket_set_nonblocking defined twice. Actually the prototype is
> not necessary at all but one may remain as a convention.
>
> It doesn't no harm
On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian wrote:
> On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
>> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote:
>> > and the units were copied when pg_size_pretty() was implemented. These
>> >
On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote:
> > and the units were copied when pg_size_pretty() was implemented. These
> > units are based on the International System of Units (SI)/metric.
> > However, the
On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote:
> The Postgres docs specify that kB is based on 1024 or 2^10:
>
> https://www.postgresql.org/docs/9.6/static/functions-admin.html
>
> Note: The units kB, MB, GB and TB used by the functions
>
On Tue, Aug 2, 2016 at 9:58 PM, Tomas Vondra
wrote:
> Attached is v19 of the "multivariate stats" patch series - essentially v18
> rebased on top of current master.
Tom:
ISTR that you were going to try to look at this patch set. It seems
from the discussion that
On 24 August 2016 at 00:50, Andres Freund wrote:
> On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote:
> > On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner
> wrote:
> > [an explanation of SSI anomalies]
>
I've generally a bit of difficulty to see this as a
On 23 August 2016 at 22:18, Robert Haas wrote:
> On Mon, Aug 22, 2016 at 8:55 PM, Craig Ringer
> wrote:
> > Updated patch series attached. As before, 0-4 intended for commit, 5 just
> > because it'll be handy to have around for people doing
On Tue, Aug 16, 2016 at 2:43 AM, Alexander Korotkov
wrote:g of pg_operator.oprassociative...
> Another problem is computational complexity of such transformations. AFAIR,
> few patches for making optimizer smarter with expressions were already
> rejected because of
On 2016-08-23 11:42:53 -0400, Robert Haas wrote:
> I think this could possibly be done, but it seems a lot better to me
> to just bite the bullet and add a new protocol message. That was
> proposed by Tom Lane on July 31st and I think it's still by far the
> best and easiest idea proposed, except
On 2016-08-23 18:18:57 +0300, Heikki Linnakangas wrote:
> I installed Greg Smith's pgbench-tools kit on that server, and ran some
> tests. I'm seeing some benefit on "pgbench -N" workload, but only after
> modifying the test script to use "-M prepared", and using Unix domain
> sockets instead of
On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote:
> On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner wrote:
> > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer wrote:
>
> >> Could you provide an example of a case where xacts replayed in
> >> commit order
On 2016-08-23 12:17:30 -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> 2. When you finish the heap scan, or when the array of dead tuple IDs
> >> is full (or very nearly full?), perform a cycle of index
On 24 August 2016 at 00:26, Kevin Grittner wrote:
> On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner wrote:
> > On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner
> wrote:
> >> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer
On Tue, Aug 23, 2016 at 10:10 AM, Antonin Houska wrote:
> I'm failing to understand why [1] mentions "table-rewriting forms of ALTER
> TABLE" besides TRUNCATE command.
>
> For TRUNCATE it seems clear: if transaction A takes the snapshot before it
> accesses the table first time
On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner wrote:
> On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner wrote:
>> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer wrote:
>>> On 23 Aug 2016 20:10, "Kevin Grittner"
Robert Haas wrote:
> On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> 2. When you finish the heap scan, or when the array of dead tuple IDs
> >> is full (or very nearly full?), perform a cycle of index vacuuming.
> >> For now, have
On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> 2. When you finish the heap scan, or when the array of dead tuple IDs
>> is full (or very nearly full?), perform a cycle of index vacuuming.
>> For now, have each worker process a separate
On Tue, Aug 23, 2016 at 10:50 PM, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 7:02 AM, Masahiko Sawada
> wrote:
>> I'd like to propose block level parallel VACUUM.
>> This feature makes VACUUM possible to use multiple CPU cores.
>
> Great. This is
On Tue, Aug 16, 2016 at 4:48 PM, Andres Freund wrote:
> One approach to solving this, without changing the protocol, would be to
> "fuse" parse/bind/execute/sync together, by peeking ahead in the
> protocol stream. When that combination is seen looking ahead (without
>
On 08/22/2016 08:38 PM, Andres Freund wrote:
On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote:
I
remember seeing ProcArrayLock contention very visible earlier, but I can't
hit that now. I suspect you'd still see contention on bigger hardware,
though, my laptop has oly 4 cores. I'll have
Robert Haas wrote:
> 2. When you finish the heap scan, or when the array of dead tuple IDs
> is full (or very nearly full?), perform a cycle of index vacuuming.
> For now, have each worker process a separate index; extra workers just
> wait. Perhaps use the condition variable patch that I posted
Thank you everyone for great comments!
> have a permanent pg_class which holds the records for permanent tables
> and an *unlogged* table, say pg_class_unlogged, which holds records
> for temporary tables. Now everybody can see everybody else's data,
> yet we don't have to create permanent
On 23/08/16 15:59, Robert Haas wrote:
On Mon, Aug 22, 2016 at 4:32 PM, Andres Freund wrote:
On 2016-08-22 16:29:12 -0400, Robert Haas wrote:
So, I wish I could give you some better advice on this topic, but
sadly I am not an expert in this area. However, it seems to me
On Mon, Aug 22, 2016 at 8:18 PM, Thomas Munro
wrote:
> On Tue, Aug 23, 2016 at 8:41 AM, Robert Haas wrote:
>> We could test to see how much it slows things down. But it
>> may be worth paying the cost even if it ends up being kinda
On Mon, 22 Aug 2016 10:53:25 -0400
Peter Eisentraut wrote:
> On 8/22/16 9:32 AM, Tatsuo Ishii wrote:
> > I don't know what kind of problem you are seeing with encoding
> > handling, but at least UTF-8 is working for Japanese, French and
> > Russian.
>
> Those
Hello devs,
When \sleep is used within a pgbench script it resets txn_scheduled which
is used for computing stats about the transaction, resulting in absurd
statistics:
latency average = 0.649 ms *** ??? ***
...
script statistics:
- statement latencies in milliseconds:
0.235
On Tue, Aug 23, 2016 at 9:40 PM, Alexander Korotkov
wrote:
> On Tue, Aug 23, 2016 at 3:32 PM, Tom Lane wrote:
>>
>> Claudio Freire writes:
>> > Not only that, but from your description (I haven't read the patch,
>> > sorry),
On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner wrote:
> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer wrote:
>> On 23 Aug 2016 20:10, "Kevin Grittner" wrote:
>>>
>>> On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer
On Tue, Aug 23, 2016 at 10:18 AM, Robert Haas wrote:
> On Mon, Aug 22, 2016 at 8:55 PM, Craig Ringer wrote:
>> Updated patch series attached. As before, 0-4 intended for commit, 5 just
>> because it'll be handy to have around for people doing
On Mon, Aug 22, 2016 at 8:55 PM, Craig Ringer wrote:
> Updated patch series attached. As before, 0-4 intended for commit, 5 just
> because it'll be handy to have around for people doing wraparound related
> testing.
>
> Again, thanks for taking a look.
/me reviews a bit
I'm failing to understand why [1] mentions "table-rewriting forms of ALTER
TABLE" besides TRUNCATE command.
For TRUNCATE it seems clear: if transaction A takes the snapshot before it
accesses the table first time (typically because isolation level is at least
REPEATABLE READ) and transaction B
On Tue, Aug 23, 2016 at 2:17 AM, Ashutosh Sharma wrote:
> I have also removed the warning message that we used to get for hash index
> like 'WARNING: hash indexes are not WAL-logged and their use is discouraged'
> as this message is now no more visible w.r.t hash index
On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer wrote:
> On 23 Aug 2016 20:10, "Kevin Grittner" wrote:
>>
>> On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer
>>> Could you provide an example of a case where xacts replayed in
>>>
On Tue, Aug 23, 2016 at 8:13 AM, Erik Rijkers wrote:
> comment typo in src/backend/storage/lmgr.c attached
Committed, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Mon, Aug 22, 2016 at 4:32 PM, Andres Freund wrote:
> On 2016-08-22 16:29:12 -0400, Robert Haas wrote:
>> So, I wish I could give you some better advice on this topic, but
>> sadly I am not an expert in this area. However, it seems to me that
>> this is just one facet of a
On Tue, Aug 23, 2016 at 7:02 AM, Masahiko Sawada wrote:
> I'd like to propose block level parallel VACUUM.
> This feature makes VACUUM possible to use multiple CPU cores.
Great. This is something that I have thought about, too. Andres and
Heikki recommended it as a
1 - 100 of 134 matches
Mail list logo