On Tue, May 10, 2016 at 10:05:13AM -0500, Kevin Grittner wrote:
> On Tue, May 10, 2016 at 9:02 AM, Tom Lane wrote:
> > Kevin Grittner writes:
> >> There were 75 samples each of "disabled" and "reverted" in the
> >> spreadsheet. Averaging them all, I see this:
> >
> >> reverted: 290,660 TPS
> >>
On 5/5/16 8:33 AM, Stephen Frost wrote:
I strongly disagree with the idea that this is only an issue with the
testing system. What if we add functions in the future that are
created by initdb and *are* useful for transforms? What about casts?
There are a lot of functions in pg_catalog that a us
On May 10, 2016, at 5:56 PM, Fabrízio de Royes Mello
wrote:
> Searching for the operator in pg_operator catalog isn't enought?
Seems like overkill, but will do if there’s nothing else.
Best,
David
smime.p7s
Description: S/MIME cryptographic signature
On 5/8/16 11:29 AM, Stephen Frost wrote:
My suggestion is that, from this point forward, we add new tests to
> 9.6 only if they are closely related to a bug that is getting fixed or
> a feature that is new in 9.6. I think that's a reasonable compromise,
> but what do others think?
I'm willing t
On May 10, 2016, at 6:14 PM, Tom Lane wrote:
> Given that you're coercing both one input value and the result to text,
> I don't understand why you don't just compare the text representations.
Because sometimes the text is not equal when the casted text is. Consider
'foo'::citext = 'FOO':ci
On 5/10/16 11:42 PM, Jim Nasby wrote:
On 5/6/16 4:55 PM, Peter Geoghegan wrote:
On Fri, May 6, 2016 at 2:49 PM, Andres Freund wrote:
Jeff Janes has done astounding work in these matters. (I don't think
we credit him enough for that.)
+many.
Agreed. I'm a huge fan of what Jeff has been abl
Hi Andres,
I am extremely sorry for the delayed response. As suggested by you, I have
taken the performance readings at 128 client counts after making the
following two changes:
*1).* Removed AddWaitEventToSet(FeBeWaitSet, WL_POSTMASTER_DEATH, -1, NULL,
NULL); from pq_init(). Below is the git di
On 5/6/16 4:08 PM, Joshua D. Drake wrote:
VACUUM THEWHOLEDAMNTHING
+100
(hahahaha)
You know what? Why not? Seriously? We aren't product. This is supposed
to be a bit fun. Let's have some fun with it? It would be so easy to
turn that into a positive advocacy opportunity.
Honestly, for an o
On 5/6/16 4:55 PM, Peter Geoghegan wrote:
On Fri, May 6, 2016 at 2:49 PM, Andres Freund wrote:
Jeff Janes has done astounding work in these matters. (I don't think
we credit him enough for that.)
+many.
Agreed. I'm a huge fan of what Jeff has been able to do in this area.
I often say so. I
On 5/6/16 4:20 PM, Andres Freund wrote:
On 2016-05-06 14:15:47 -0700, Josh berkus wrote:
For the serious testing, does anyone have a good technique for creating
loads which would stress-test vacuum freezing? It's hard for me to come
up with anything which wouldn't be very time-and-resource inte
Robert Haas writes:
> On Mon, May 9, 2016 at 11:11 AM, Tom Lane wrote:
>> regression=# set force_parallel_mode TO on;
>> SET
>> regression=# explain select count(*) from tenk1;
>> QUERY PLAN
>> -
>> Aggregate (cost=483.00..483.01 ro
On 11 May 2016 at 06:47, Vladimir Gordiychuk wrote:
> Same thread, I just think these are two somewhat separate changes. One is
>> just in the walsender and allows return to command mode during waiting for
>> WAL. The other is more intrusive into the reorder buffer etc and allows
>> aborting deco
On 5/10/16 9:16 PM, David G. Johnston wrote:
Brute force: you'd have to query pg_amop and note the absence of a row
with a btree (maybe hash too...) family strategy 3 (1 for hash)
[equality] where the left and right types are the same and match the
type in question.
While these are good thought
On 8 May 2016 at 07:38, Euler Taveira wrote:
> src/include/parser/kwlist.h
Thanks Everyone.
Kwlist.h got me going as to where to look, but I had to improvise (quite) a
bit. Any and all advice about any other authoritative lists (like kwlist.h)
would be a big help, since currently much is klud
Euler Taveira writes:
> On 10-05-2016 20:59, Rob Bygrave wrote:
>> Having read all the previous discussions on the general topic of
>> altering tables with dependent views I realise this is a complex and
>> difficult issue in general but I'd like to see if there was some support
>> for looking at
On 10-05-2016 22:22, David G. Johnston wrote:
> I don't know how the docs, this function, and the source code relate to
> each other.
>
Function is built around ScanKeywords structure which in turn is built
using parser/kwlist.h.
--
Euler Taveira Timbira - http://www.timbir
On Wed, May 11, 2016 at 10:22 AM, David G. Johnston
wrote:
> On Saturday, May 7, 2016, Euler Taveira wrote:
>>
>> On 07-05-2016 22:53, Robins Tharakan wrote:
>> > Should I be looking somewhere else? Parse keywords from Git Source file
>> > (if so where)? Parse PG Documentation?
>> >
>> src/includ
On Tue, May 10, 2016 at 11:30 PM, Robert Haas wrote:
> On Mon, May 9, 2016 at 7:40 PM, Ants Aasma wrote:
>> On Mon, May 9, 2016 at 10:53 PM, Robert Haas wrote:
>>> On Sun, May 8, 2016 at 10:42 PM, Masahiko Sawada
>>> wrote:
Attached draft patch adds SCANALL option to VACUUM in order to sc
On 10-05-2016 22:28, David G. Johnston wrote:
> Technically "is not distinct from" would be more correct.
>
Ooops. Fat fingered the statement. Also, forgot to consider null case.
euler=# \pset null 'NULL'
Null display is "NULL".
euler=# select x.a, y.b, x.a IS NOT DISTINCT FROM y.b AS "INDF", x.a
On 10-05-2016 20:59, Rob Bygrave wrote:
> Having read all the previous discussions on the general topic of
> altering tables with dependent views I realise this is a complex and
> difficult issue in general but I'd like to see if there was some support
> for looking at these 3 more specific changes
On Wed, May 4, 2016 at 01:50:39PM -0700, Andres Freund wrote:
> I also want to reiterate that I didn't immediately call for a revert,
> initially - before recognizing the architectural issue - I offered to
> write code to address the regressions due to the spinlocks.
I was the same case --- I did
On Tuesday, May 10, 2016, Euler Taveira wrote:
>
> Also, IS DISTINCT FROM is an alias for = operator per standard IIRC.
>
Technically "is not distinct from" would be more correct. Alias implies
exact while in the presence of nulls the two behave differently.
"is distinct from" ~ "<>" which is
On Saturday, May 7, 2016, Euler Taveira wrote:
> On 07-05-2016 22:53, Robins Tharakan wrote:
> > Should I be looking somewhere else? Parse keywords from Git Source file
> > (if so where)? Parse PG Documentation?
> >
> src/include/parser/kwlist.h
>
http://www.postgresql.org/docs/9.5/interactive
On 10-05-2016 21:12, David E. Wheeler wrote:
> This makes sense, of course, and I could fix it by comparing text
> values instead of json values when the values are JSON. But of course
> the lack of a = operator is not limited to JSON. So I’m wondering if
> there’s an interface at the SQL level to
On Tuesday, May 10, 2016, David E. Wheeler wrote:
>
> This makes sense, of course, and I could fix it by comparing text values
> instead of json values when the values are JSON. But of course the lack of
> a = operator is not limited to JSON. So I’m wondering if there’s an
> interface at the SQL
"David E. Wheeler" writes:
> pgTAP has a function that compares two values of a given type, which it uses
> for comparing column defaults. It looks like this:
> CREATE OR REPLACE FUNCTION _def_is( TEXT, TEXT, anyelement, TEXT )
> RETURNS TEXT AS $$
Given that you're coercing both one in
Jeff Janes writes:
> But, another perhaps stupid question, why do we care what the value of
> nextOid was at the start of the last successfully completed
> checkpoint?
The intended use of that field is to restore nextOid before replaying
WAL. So it should correspond to the value at checkpoint st
On Fri, May 6, 2016 at 03:32:23PM -0400, Tom Lane wrote:
> > I think possibly the easiest fix for this is to have pg_upgrade,
> > instead of RESETting a nonexistent option, RESET something that's
> > still considered to require AccessExclusiveLock. "user_catalog_table"
> > would work, looks like;
On 2016-05-10 17:36:06 -0700, Jeff Janes wrote:
> OK, got it. I don' t know how I missed the bigger picture of that
> function in the first place.
>
> But, another perhaps stupid question, why do we care what the value of
> nextOid was at the start of the last successfully completed
> checkpoint?
Em terça-feira, 10 de maio de 2016, David E. Wheeler
escreveu:
> Hackers,
>
> pgTAP has a function that compares two values of a given type, which it
> uses for comparing column defaults. It looks like this:
>
> CREATE OR REPLACE FUNCTION _def_is( TEXT, TEXT, anyelement, TEXT )
> RETURNS
On Tue, May 3, 2016 at 12:07:51PM -0400, Tom Lane wrote:
> I think possibly the easiest fix for this is to have pg_upgrade,
> instead of RESETting a nonexistent option, RESET something that's
> still considered to require AccessExclusiveLock. "user_catalog_table"
> would work, looks like; though
On 2016-05-11 03:20:12 +0300, Ants Aasma wrote:
> On Tue, May 10, 2016 at 7:56 PM, Robert Haas wrote:
> > On Mon, May 9, 2016 at 8:34 PM, David Rowley
> > wrote:
> > I don't have any at the moment, but I'm not keen on hundreds of new
> > vector functions that can all have bugs or behavior differe
On 2016-05-10 12:56:17 -0400, Robert Haas wrote:
> I suspect the number of queries that are being hurt by fmgr overhead
> is really large, and I think it would be nice to attack that problem
> more directly. It's a bit hard to discuss what's worthwhile in the
> abstract, without performance number
On Tue, May 10, 2016 at 4:02 PM, Andres Freund wrote:
> On 2016-05-10 15:53:38 -0700, Jeff Janes wrote:
>>
>> But isn't CreateCheckPoint called at the end of the checkpoint, not
>> the start of it?
>
> No, CreateCheckPoint() does it all.
>
>
> CreateCheckPoint(int flags)
> {
> ...
> /* 1) dete
On 2016-05-10 12:34:19 +1200, David Rowley wrote:
> a. Modify ScanAPI to allow batch tuple fetching in predefined batch sizes.
> b. Modify TupleTableSlot to allow > 1 tuple to be stored. Add flag to
> indicate if the struct contains a single or a multiple tuples.
> Multiple tuples may need to be de
On Tue, May 10, 2016 at 7:56 PM, Robert Haas wrote:
> On Mon, May 9, 2016 at 8:34 PM, David Rowley
> wrote:
> I don't have any at the moment, but I'm not keen on hundreds of new
> vector functions that can all have bugs or behavior differences versus
> the unvectorized versions of the same code.
Hackers,
pgTAP has a function that compares two values of a given type, which it uses
for comparing column defaults. It looks like this:
CREATE OR REPLACE FUNCTION _def_is( TEXT, TEXT, anyelement, TEXT )
RETURNS TEXT AS $$
DECLARE
thing text;
BEGIN
IF $1 ~ '^[^'']
I have read the prior discussions linked from
https://wiki.postgresql.org/wiki/Todo#Views_and_Rules
What I would like to do is put the specific case for handling 3 common
'alter column' changes when that column is referenced in a view.
Take the case of:
create table base_table ( id bigserial, ac
Hi,
On 2016-05-09 13:33:55 -0400, Robert Haas wrote:
> I think there are several different areas
> where we should consider major upgrades to our executor. It's too
> slow and it doesn't do everything we want it to do. The main things
> on my mind are:
3) We use a lot of very cache-inefficient
On 2016-05-10 15:53:38 -0700, Jeff Janes wrote:
> On Tue, May 10, 2016 at 2:00 PM, Andres Freund wrote:
> > I think that's to blame here. Looking at the relevant WAL record shows:
> >
> > pg_xlogdump -p /data/freund/jj -s 2/12004018 -e 2/1327EA28|grep -E
> > 'CHECKPOINT|NEXTOID'
> > rmgr: XLOG
Andres Freund writes:
> On 2016-05-10 18:29:59 -0400, Tom Lane wrote:
>> Having said that, I still say that changing HeapTupleSatisfiesToast
>> is the wrong thing. It can't go deciding not to return toast values
>> because they're committed dead --- the parent tuple could easily be
>> committed d
On Tue, May 10, 2016 at 2:00 PM, Andres Freund wrote:
> On 2016-05-10 09:19:16 -0700, Andres Freund wrote:
>> On 2016-05-10 08:09:02 -0400, Robert Haas wrote:
>> > On Tue, May 10, 2016 at 3:05 AM, Andres Freund wrote:
>> > > The easy way to trigger this problem would be to have an oid wraparound
>
> Same thread, I just think these are two somewhat separate changes. One is
> just in the walsender and allows return to command mode during waiting for
> WAL. The other is more intrusive into the reorder buffer etc and allows
> aborting decoding during commit processing. So two separate patches
On 2016-05-10 18:29:59 -0400, Tom Lane wrote:
> Now having said that, you don't actually need *rapid* advancement
> of the OID counter to have a potential problem. Imagine that some
> transaction inserts a TOAST value and later fails, so that you have
> a dead-but-unhinted toast tuple sitting ther
Andres Freund writes:
> On 2016-05-10 16:14:50 -0400, Tom Lane wrote:
>> I think the problem is pretty hypothetical until you get to consuming a
>> substantial part of the OID space within any one toast table, at which
>> point you're going to need 8-byte toast OIDs. Improving that situation
>> s
Hi,
On 2016-05-06 21:21:11 +0530, Mithun Cy wrote:
> I will try to run the tests as you have suggested and will report the same.
Any news on that front?
Regards,
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On 2016-05-10 13:17:52 -0700, Jeff Janes wrote:
> On Tue, May 10, 2016 at 9:19 AM, Andres Freund wrote:
> > On 2016-05-10 08:09:02 -0400, Robert Haas wrote:
> >> On Tue, May 10, 2016 at 3:05 AM, Andres Freund wrote:
> >> > The easy way to trigger this problem would be to have an oid wraparound
>
On 2016-05-10 16:14:50 -0400, Tom Lane wrote:
> I think the problem is pretty hypothetical until you get to consuming a
> substantial part of the OID space within any one toast table, at which
> point you're going to need 8-byte toast OIDs. Improving that situation
> seems like something we can de
On 2016-05-10 15:20:39 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Robert Haas writes:
> > > On Tue, May 10, 2016 at 12:19 PM, Andres Freund
> > > wrote:
> > >> It's not super likely, yea. But you don't really need to "use" 4 billion
> > >> oids to get a wraparound. Once you have a signif
On 2016-05-10 13:36:32 -0400, Robert Haas wrote:
> On Tue, May 10, 2016 at 12:31 PM, Tomas Vondra
> wrote:
> > The following table shows the differences between the disabled and reverted
> > cases like this:
> >
> > sum('reverted' results with N clients)
> >
On Tue, May 10, 2016 at 2:41 PM, Kevin Grittner wrote:
> http://www.postgresql.org/message-id/flat/1402267501.4.yahoomail...@web122304.mail.ne1.yahoo.com
Re-reading that thread I was reminded that I had more NUMA problems
when data all landed in one memory node, as can happen with pgbench
-i
hmm, the morsels paper looks really interesting at first sight.
Let's see if we can get a poc working in PostgreSQL? :-)
On Tue, May 10, 2016 at 9:42 PM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> On 05/10/2016 08:26 PM, Robert Haas wrote:
>
>> On Tue, May 10, 2016 at 3:00 AM, kons
On 2016-05-10 09:19:16 -0700, Andres Freund wrote:
> On 2016-05-10 08:09:02 -0400, Robert Haas wrote:
> > On Tue, May 10, 2016 at 3:05 AM, Andres Freund wrote:
> > > The easy way to trigger this problem would be to have an oid wraparound
> > > - but the WAL shows that that's not the case here. I'
On 5/10/16 12:47 AM, Kouhei Kaigai wrote:
> On 10 May 2016 at 13:38, Kouhei Kaigai wrote:
> > My concern about ExecProcNode is, it is constructed with a large switch
> > ... case statement. It involves tons of comparison operation at run-time.
> > If we replace this switch ... case by function
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> The subquery comparing the OID of pg_class using only a condition on
> relname seems wrong; wouldn't it fail or produce wrong results if
> somebody creates a table named pg_class in another schema? I think you
> should write the compari
On Tue, May 10, 2016 at 9:19 AM, Andres Freund wrote:
> On 2016-05-10 08:09:02 -0400, Robert Haas wrote:
>> On Tue, May 10, 2016 at 3:05 AM, Andres Freund wrote:
>> > The easy way to trigger this problem would be to have an oid wraparound
>> > - but the WAL shows that that's not the case here. I
Alvaro Herrera writes:
> Tom Lane wrote:
>> Sooner or later we are going to need to go to 8-byte TOAST object
>> identifiers. Maybe we should think about doing that sooner not later
>> rather than trying to invent some anti-wraparound solution here.
> Umm, it seems to me like we need this fixed
On 05/10/2016 08:26 PM, Robert Haas wrote:
On Tue, May 10, 2016 at 3:00 AM, konstantin knizhnik
wrote:
What's wrong with it that worker is blocked? You can just have more workers
(more than CPU cores) to let other of them continue to do useful work.
Not really. The workers are all running the
On Tue, May 10, 2016 at 11:13 AM, Tomas Vondra
wrote:
> On 05/10/2016 10:29 AM, Kevin Grittner wrote:
>> On Mon, May 9, 2016 at 9:01 PM, Tomas Vondra
>> wrote:
>>> * It's also seems to me the feature greatly amplifies the
>>> variability of the results, somehow. It's not uncommon to see
>>> res
On 10 May 2016 at 17:20, Andres Freund wrote:
> On 2016-05-10 12:28:57 +0200, Simon Riggs wrote:
> > On 10 May 2016 at 09:05, Andres Freund wrote:
> >
> >
> > > Is anybody ready with a good defense for SatisfiesToast not doing any
> > > actual liveliness checks?
> > >
> >
> > I provided a patch
Hi,
On 05/10/2016 07:36 PM, Robert Haas wrote:
On Tue, May 10, 2016 at 12:31 PM, Tomas Vondra
wrote:
The following table shows the differences between the disabled and reverted
cases like this:
sum('reverted' results with N clients)
- 1.0
su
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, May 10, 2016 at 12:19 PM, Andres Freund wrote:
> >> It's not super likely, yea. But you don't really need to "use" 4 billion
> >> oids to get a wraparound. Once you have a significant number of values
> >> in various toast tables, the oid counter
Robert Haas writes:
> On Tue, May 10, 2016 at 12:19 PM, Andres Freund wrote:
>> It's not super likely, yea. But you don't really need to "use" 4 billion
>> oids to get a wraparound. Once you have a significant number of values
>> in various toast tables, the oid counter progresses really rather f
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
> > index 1267afb..4a9b1bf 100644
> > --- a/src/bin/pg_dump/pg_dump.c
> > +++ b/src/bin/pg_dump/pg_dump.c
> > @@ -14992,9 +14992,10 @@ dumpTable(Archiv
Stephen Frost wrote:
> diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
> index 1267afb..4a9b1bf 100644
> --- a/src/bin/pg_dump/pg_dump.c
> +++ b/src/bin/pg_dump/pg_dump.c
> @@ -14992,9 +14992,10 @@ dumpTable(Archive *fout, TableInfo *tbinfo)
>
On Tue, May 10, 2016 at 12:19 PM, Andres Freund wrote:
>> I assume that this was installed as a performance optimization, and I
>> don't really see why it shouldn't be or be able to be made safe. I
>> assume that the wraparound case was deemed safe because at that time
>> the idea of 4 billion OI
On Tue, May 10, 2016 at 12:31 PM, Tomas Vondra
wrote:
> The following table shows the differences between the disabled and reverted
> cases like this:
>
> sum('reverted' results with N clients)
> - 1.0
> sum('disabled' results with N clients)
>
>
On Tue, May 10, 2016 at 3:00 AM, konstantin knizhnik
wrote:
> What's wrong with it that worker is blocked? You can just have more workers
> (more than CPU cores) to let other of them continue to do useful work.
Not really. The workers are all running the same plan, so they'll all
make the same d
On Mon, May 9, 2016 at 9:38 PM, Kouhei Kaigai wrote:
> Is the parallel aware Append node sufficient to run multiple nodes
> asynchronously? (Sorry, I couldn't have enough time to code the feature
> even though we had discussion before.)
It's tempting to think that parallel query and asynchronous
On 11 May 2016 at 01:15, Vladimir Gordiychuk wrote:
> in which release can be include first part?
>
Since it's not a bug fix, I don't think it can go in before 9.7.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
in which release can be include first part?
2016-05-10 15:15 GMT+03:00 Craig Ringer :
> On 10 May 2016 at 19:41, Vladimir Gordiychuk wrote:
>
>>
>> Fair enough. Though I don't understand why you'd be doing this often
>>> enough that you'd care about reopening connections. What is the problem you
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Apr 05, 2016 at 05:50:18PM -0400, Stephen Frost wrote:
> > @@ -14187,18 +14869,65 @@ dumpTable(Archive *fout, TableInfo *tbinfo)
>
> > + "FROM
> > pg_catalog.pg_attribute at "
> > +
On Mon, May 9, 2016 at 8:34 PM, David Rowley
wrote:
> It's interesting that you mention this. We identified this as a pain
> point during our work on column stores last year. Simply passing
> single tuples around the executor is really unfriendly towards L1
> instruction cache, plus also the point
On 05/10/2016 03:04 PM, Kevin Grittner wrote:
On Tue, May 10, 2016 at 3:29 AM, Kevin Grittner mailto:kgri...@gmail.com>> wrote:
* The results are a bit noisy, but I think in general this shows
that for certain cases there's a clearly measurable difference
(up to 5%) between the "disabled" and
On 2016-05-10 10:09:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Is anybody ready with a good defense for SatisfiesToast not doing any
> > actual liveliness checks?
>
> As long as we do not update toast values after creation, there is no
> need; the liveness check on the parent tuple is
Tomas Vondra wrote:
> Yes, I'd like to repeat the tests with other workloads - I'm thinking about
> regular pgbench and perhaps something that'd qualify as 'mostly read-only'
> (not having a clear idea how that should work).
You can use "-bselect-only@9 -bsimple-update@1" for a workload that's
10
On 2016-05-10 12:28:57 +0200, Simon Riggs wrote:
> On 10 May 2016 at 09:05, Andres Freund wrote:
>
>
> > Is anybody ready with a good defense for SatisfiesToast not doing any
> > actual liveliness checks?
> >
>
> I provided a patch earlier that rechecks the OID fetched from a toast chunk
> matc
On 2016-05-10 08:09:02 -0400, Robert Haas wrote:
> On Tue, May 10, 2016 at 3:05 AM, Andres Freund wrote:
> > The easy way to trigger this problem would be to have an oid wraparound
> > - but the WAL shows that that's not the case here. I've not figured
> > that one out entirely (and won't tonight
Hi,
On 05/10/2016 10:29 AM, Kevin Grittner wrote:
On Mon, May 9, 2016 at 9:01 PM, Tomas Vondra
mailto:tomas.von...@2ndquadrant.com>> wrote:
Over the past few days I've been running benchmarks on a fairly
large NUMA box (4 sockets, 32 cores / 64 with HR, 256GB of RAM)
to see the impact of the '
On Tue, May 10, 2016 at 9:02 AM, Tom Lane wrote:
> Kevin Grittner writes:
>> There were 75 samples each of "disabled" and "reverted" in the
>> spreadsheet. Averaging them all, I see this:
>
>> reverted: 290,660 TPS
>> disabled: 292,014 TPS
>
>> That's a 0.46% overall increase in performance wi
On Mon, May 9, 2016 at 7:40 PM, Ants Aasma wrote:
> On Mon, May 9, 2016 at 10:53 PM, Robert Haas wrote:
>> On Sun, May 8, 2016 at 10:42 PM, Masahiko Sawada
>> wrote:
>>> Attached draft patch adds SCANALL option to VACUUM in order to scan
>>> all pages forcibly while ignoring visibility map info
Andres Freund writes:
> Is anybody ready with a good defense for SatisfiesToast not doing any
> actual liveliness checks?
As long as we do not update toast values after creation, there is no
need; the liveness check on the parent tuple is what's important.
Adding a liveness check on the toast ite
Kevin Grittner writes:
> There were 75 samples each of "disabled" and "reverted" in the
> spreadsheet. Averaging them all, I see this:
> reverted: 290,660 TPS
> disabled: 292,014 TPS
> That's a 0.46% overall increase in performance with the patch,
> disabled, compared to reverting it. I'm su
On Tue, May 10, 2016 at 3:29 AM, Kevin Grittner wrote:
>> * The results are a bit noisy, but I think in general this shows
>> that for certain cases there's a clearly measurable difference
>> (up to 5%) between the "disabled" and "reverted" cases. This is
>> particularly visible on the smallest d
Hi!
On Mon, May 9, 2016 at 10:46 PM, Andres Freund wrote:
> trying to debug something I saw the following in pg_xlogdump output:
>
> rmgr: Gin len (rec/tot): 0/ 274, tx: 0, lsn:
> 1C/DF28AEB0, prev 1C/DF289858, desc: VACUUM_DATA_LEAF_PAGE 3 segments: 5
> unknown action 0
On Mon, May 9, 2016 at 10:25 AM, Christian Ullrich wrote:
> here is a patch for the German translation that removes (all) five instances
> of *the* most annoying mistake ever.
Wow, glad it got fixed. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 10 May 2016 at 19:41, Vladimir Gordiychuk wrote:
>
> Fair enough. Though I don't understand why you'd be doing this often
>> enough that you'd care about reopening connections. What is the problem you
>> are trying to solve with this? The underlying reason you need this change?
>>
>
> First re
For making hash indexes usable in production systems, we need to improve
its concurrency and make them crash-safe by WAL logging them. The first
problem I would like to tackle is improve the concurrency of hash
indexes. First
advantage, I see with improving concurrency of hash indexes is that it
On Tue, May 10, 2016 at 3:05 AM, Andres Freund wrote:
> The easy way to trigger this problem would be to have an oid wraparound
> - but the WAL shows that that's not the case here. I've not figured
> that one out entirely (and won't tonight). But I do see WAL records
> like:
> rmgr: XLOGl
On 09 May 2016 23:04, Robert Haas Wrote:
>2. vectorized execution, by which I mean the ability of a node to return
>tuples in batches rather than one by one. Andres has opined more than
>once that repeated trips through ExecProcNode defeat the ability of the
>CPU to do branch prediction correctly
> Fair enough. Though I don't understand why you'd be doing this often
> enough that you'd care about reopening connections. What is the problem you
> are trying to solve with this? The underlying reason you need this change?
>
First reason it clear API in pgjdc. Second reason it ability fast enou
Hi Ashutosh,
On 2016/05/09 20:21, Ashutosh Bapat wrote:
> Hi Amit,
> I am trying multi-column/expression partitions.
Thanks for the tests.
> create table t1_multi_col (a int, b int) partition by range (a, b);
> create table t1_mc_p1 partition of t1_multi_col for values start (1, 200)
> end (100
On 10 May 2016 at 09:05, Andres Freund wrote:
> Is anybody ready with a good defense for SatisfiesToast not doing any
> actual liveliness checks?
>
I provided a patch earlier that rechecks the OID fetched from a toast chunk
matches the OID requested.
I didn't commit it, I just used it to check
Hello.
At Mon, 9 May 2016 13:33:55 -0400, Robert Haas wrote in
> Hi,
>
> I realize that we haven't gotten 9.6beta1 out the door yet, but I
> think we can't really wait much longer to start having at least some
> discussion of 9.7 topics, so I'm going to go ahead and put this one
> out there.
On Tue, May 10, 2016 at 7:41 AM, David Rowley
wrote:
> On 10 May 2016 at 16:34, David G. Johnston
> wrote:
> > On Mon, May 9, 2016 at 8:53 AM, Benedikt Grundmann
> > wrote:
> >>
> >> We just run into a very simple query that the planner does much worse on
> >> than we thought it would (in produ
On Mon, May 9, 2016 at 9:01 PM, Tomas Vondra
wrote:
> Over the past few days I've been running benchmarks on a fairly
> large NUMA box (4 sockets, 32 cores / 64 with HR, 256GB of RAM)
> to see the impact of the 'snapshot too old' - both when disabled
> and enabled with various values in the old_s
On 2016/05/02 22:06, Robert Haas wrote:
On Thu, Apr 28, 2016 at 7:59 AM, Etsuro Fujita
wrote:
On 2016/03/14 17:56, Ashutosh Bapat wrote:
On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
/*
* Build the fdw_private list that will be
Hi,
On 2016-04-29 10:38:55 -0700, Jeff Janes wrote:
> I've bisected the errors I was seeing, discussed in
> http://www.postgresql.org/message-id/CAMkU=1xqehc0ok4d+tkjfq1nvuho37pyrkhjp6q8oxifmx7...@mail.gmail.com
>
> It look like they first appear in:
>
> commit 48354581a49c30f5757c203415aa8412d85b
Hi,
> 1. asynchronous execution,
It seems to me that asynchronous execution can be considered as alternative to
multithreading model (in case of PostgreSQL the roles of threads are played by
workers).
Async. operations are used to have smaller overhead but have scalability
problems (because i
99 matches
Mail list logo
