On 06/02/14 16:59, Robert Haas wrote:
On Wed, Feb 5, 2014 at 6:43 AM, Heikki Linnakangas
wrote:
So, I came up with the attached worst case test, modified from your latest
test suite.
unpatched:
testname | wal_generated | duration
Robert Haas writes:
> On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera
> wrote:
>>> Then again, why is the behavior of schema-qualifying absolutely
>>> everything even desirable?
>> Well, someone could create a collation in another schema with the same
>> name as a system collation and the comman
On 02/04/2014 02:43 PM, Craig Ringer wrote:
> On 01/30/2014 04:05 PM, Craig Ringer wrote:
>> On 01/30/2014 01:25 PM, Craig Ringer wrote:
>>> On 01/29/2014 09:47 PM, Craig Ringer wrote:
https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
i.e. https://github.com/ringerc/po
Some more thoughts:
Please add comments above _bt_mark_page_halfdead(), a new routine from
the dependency patch. I realize that this is substantially similar to
part of how _bt_pagedel() used to work, but it's still incongruous.
> ! Our approach is to create any missing downlinks on-they-fly, whe
On Wed, Feb 5, 2014 at 6:43 AM, Heikki Linnakangas
wrote:
> So, I came up with the attached worst case test, modified from your latest
> test suite.
>
> unpatched:
>
>
>testname | wal_generated | duration
> --+---+--
On Wed, Feb 5, 2014 at 8:50 PM, Heikki Linnakangas
wrote:
> On 02/05/2014 04:48 PM, Amit Kapila wrote:
>>
>> I have done one test where there is a large suffix match, but
>> not large enough that it can compress more than 75% of string,
>> the CPU overhead with wal-update-prefix-suffix-encode-1.pa
On Wed, Feb 5, 2014 at 6:59 AM, Heikki Linnakangas
wrote:
> Attached is a quick patch for that, if you want to test it.
But if we really just want to do prefix/suffix compression, this is a
crappy and expensive way to do it. We needn't force everything
through the pglz tag format just because we
On Wed, Feb 5, 2014 at 6:58 PM, Marti Raudsepp wrote:
> I ran some synthetic benchmarks with single-column inner joins between 5
> tables, with indexes on both joined columns, using only EXPLAIN (so
> measuring planning time, not execution) in 9 scenarios to excercise
> different code paths. Accor
On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera wrote:
>> Then again, why is the behavior of schema-qualifying absolutely
>> everything even desirable?
>
> Well, someone could create a collation in another schema with the same
> name as a system collation and the command would become ambiguous. Fo
On 02/06/2014 10:14 AM, Craig Ringer wrote:
> On 02/05/2014 01:52 PM, Tom Lane wrote:
>> Craig Ringer writes:
>>> On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT-sprinkling approach
(not happy with it, of course, but prepared to tolerate it) as long
>>
On 02/05/2014 01:52 PM, Tom Lane wrote:
> Craig Ringer writes:
>> On 02/05/2014 06:29 AM, Tom Lane wrote:
>>> I had been okay with the manual PGDLLIMPORT-sprinkling approach
>>> (not happy with it, of course, but prepared to tolerate it) as long
>>> as I believed the buildfarm would reliably tell
On Tue, Feb 4, 2014 at 11:56 PM, Heikki Linnakangas
wrote:
> I also changed _bt_moveright to never return a write-locked buffer, when the
> caller asked for a read-lock (an issue you pointed out earlier in this
> thread).
I think that _bt_moveright() looks good now.
There is now bitrot, caused b
On Tue, Jan 28, 2014 at 7:51 AM, Alexander Korotkov wrote:
> On Tue, Jan 28, 2014 at 7:41 AM, Marti Raudsepp wrote:
>
>> But some benchmarks of planning performance are certainly warranted.
>>
>
> I didn't test it, but I worry that overhead might be high.
> If it's true then it could be like cons
On 02/05/2014 01:10 PM, Andrew Dunstan wrote:
On 02/05/2014 12:48 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/05/2014 11:40 AM, Tom Lane wrote:
switching to "binary is the same as text" may well be the most prudent
path here.
If we do that we're going to have to live with that forever
On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan wrote:
> So while post-recovery callbacks no longer exist for any
> rmgr-managed-resource, 100% of remaining startup and cleanup callbacks
> concern the simple management of memory of AM-specific recovery
> contexts (for GiST, GiN and SP-GiST). I ha
Andres Freund writes:
> On 2014-02-05 14:07:29 -0500, Tom Lane wrote:
>> I stuck such an Assert in ScanPgRelation, and verified that it doesn't
>> break any existing regression tests --- although of course the above
>> test case still fails, and now even without declaring an index.
>>
>> Barring
On 2014-02-05 14:07:29 -0500, Tom Lane wrote:
> I stuck such an Assert in ScanPgRelation, and verified that it doesn't
> break any existing regression tests --- although of course the above
> test case still fails, and now even without declaring an index.
>
> Barring objections I'll go commit that
On Wed, Feb 05, 2014 at 02:07:29PM -0500, Tom Lane wrote:
> Of course, a direct system catalog scan is certainly no safer in an
> aborted transaction than the one that catcache.c is refusing to do.
> Therefore, in my opinion, relcache.c ought also to be doing an
> Assert(IsTransactionState()), at l
On Tue, Feb 4, 2014 at 5:22 PM, Jeremy Harris wrote:
> The attached patch replaces the existing siftup method for heapify with
> a siftdown method. Tested with random integers it does 18% fewer
> compares and takes 10% less time for the heapify, over the work_mem
> range 1024 to 1048576.
>
> Both
First, thanks for this thoughtful email.
On Tue, Feb 4, 2014 at 7:14 PM, Jeff Janes wrote:
> On Mon, Feb 3, 2014 at 8:55 AM, Robert Haas wrote:
>> I've also had some further thoughts about the right way to drive
>> vacuum scheduling. I think what we need to do is tightly couple the
>> rate at w
On 02/05/2014 04:06 PM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 3:03 PM, Josh Berkus wrote:
That was the original goal. However, Oleg and Teodor's late delivery of
Hstore2 limited what Andrew could do for JSONB before CF4 started.
I also had issues. But this is the sort of thing that h
On Wed, Feb 5, 2014 at 3:03 PM, Josh Berkus wrote:
> That was the original goal. However, Oleg and Teodor's late delivery of
> Hstore2 limited what Andrew could do for JSONB before CF4 started.
yeah. anyways, I'm good on this point.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Merlin,
> Not following this. I do not see how the presence of jsonb helps at
> all. Client to server communication will be text->binary (and vice
> versa) and handling within the server itself will be in binary. This
> is the crux of my point.
Except that handling it on the server, in binary,
On 02/05/2014 03:45 PM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 2:37 PM, Andrew Dunstan wrote:
The time for this discussion was months ago. I would not have spent many
many hours of my time if I thought it was going to be thrown away. I find
this attitude puzzling, to say the least. You w
On Wed, Feb 5, 2014 at 2:37 PM, Andrew Dunstan wrote:
> The time for this discussion was months ago. I would not have spent many
> many hours of my time if I thought it was going to be thrown away. I find
> this attitude puzzling, to say the least. You were a major part of the
> discussion when we
On 02/05/2014 03:15 PM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 1:03 PM, Josh Berkus wrote:
On 02/05/2014 07:48 AM, Merlin Moncure wrote:
Another point I'm struggling with is
what jsonb brings to the table that isn't covered either hstore or
json; working through a couple of cases I find
On Wed, Feb 5, 2014 at 1:03 PM, Josh Berkus wrote:
> On 02/05/2014 07:48 AM, Merlin Moncure wrote:
>> Another point I'm struggling with is
>> what jsonb brings to the table that isn't covered either hstore or
>> json; working through a couple of cases I find myself not using the
>> jsonb functiona
Alvaro Herrera writes:
> Robert Haas escribió:
>> How about doing whatever pg_dump does?
> We use format_type() for that as far as I know. What it does
> differently is use undecorated names defined by the standard for some
> types, which are never schema qualified and are never ambiguous becaus
On 02/05/2014 10:56 AM, Andrew Dunstan wrote:
It appears that LLVM supports Windows:
http://llvm.org/docs/GettingStartedVS.html
If someone wants to work on getting a Windows build working with llvm
then go for it. But until then the Mingw tools are the only thing we
have that we know wor
Robert Haas escribió:
> On Tue, Feb 4, 2014 at 12:11 AM, Alvaro Herrera
> wrote:
> > I have run into some issues, though:
> >
> > 1. certain types, particularly timestamp/timestamptz but really this
> > could happen for any type, have unusual typmod output behavior. For
> > those one cannot just
On 02/05/2014 02:03 PM, Josh Berkus wrote:
Frankly, if it were entirely up to me HSTORE2 would be part of core and
its only interface would be JSONB. But it's not. So this is a compromise.
You could only do that by inventing a new type. But hstore2 isn't a new
type, it's meant to be the e
Robert Haas writes:
> On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane wrote:
>> Actually the part of that that bothers me is "xmin", which conflicts
>> with a reserved system column name. While you can legally pick such
>> conflicting names for view columns, it's not going to be so much fun
>> when you
Noah Misch writes:
> The following test case reliably hits this new assertion:
> create table t (c int);
> begin;
> create index on t (c);
> savepoint q;
> insert into t values (1);
> select 1/0;
As of commit ac8bc3b6e4, this test case no longer triggers the assertion,
because it depends on the
On 02/05/2014 07:48 AM, Merlin Moncure wrote:
> Another point I'm struggling with is
> what jsonb brings to the table that isn't covered either hstore or
> json; working through a couple of cases I find myself not using the
> jsonb functionality except as a 'hstore json formatter' which the json
>
On Wed, Feb 5, 2014 at 12:50 AM, Heikki Linnakangas
wrote:
>> I think there's zero overlap. They're completely complimentary features.
>> It's not like normal WAL records have an irrelevant volume.
>
>
> Correct. Compressing a full-page image happens on the first update after a
> checkpoint, and t
On 02/05/2014 01:41 PM, Joshua D. Drake wrote:
On 02/03/2014 07:04 AM, Robert Haas wrote:
On Mon, Feb 3, 2014 at 9:57 AM, Andrew Dunstan
wrote:
It's not so long ago that they were saying they would no longer publish
free-as-in-beer command line compilers at all. The outrage made them
chan
On Tue, Feb 4, 2014 at 11:25 AM, Christoph Berg
wrote:
> Re: To Tom Lane 2014-01-08 <20140108094017.ga20...@msgid.df7cb.de>
>> What about this patch to mention this gotcha more explicitely in the
>> documentation?
>>
>> diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
>> new fi
On 2/5/14, 1:31 PM, Robert Haas wrote:
> On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
>> Perhaps this type should be called pglsn, since it's an
>> implementation-specific detail and not a universal concept like int,
>> point, or uuid.
>
> If we're going to do that, I suggest pg_lsn ra
On Tue, Feb 4, 2014 at 4:24 PM, Peter Geoghegan wrote:
> There is something you have not drawn explicit attention to that is
> very interesting. If we take REL9_3_STABLE tip to be representative
> (built with full -O2 optimization, no assertions just debugging
> symbols), setting max_connections t
On 02/03/2014 07:04 AM, Robert Haas wrote:
On Mon, Feb 3, 2014 at 9:57 AM, Andrew Dunstan wrote:
It's not so long ago that they were saying they would no longer publish
free-as-in-beer command line compilers at all. The outrage made them change
their minds, but we really can't rely on only Mi
On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> It feels weird to me that the new columns are called transactionid and
>> xmin. Why not xid and xmin?
>
> Actually the part of that that bothers me is "xmin", which conflicts
> with a reserved system column name. While you
On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
> Perhaps this type should be called pglsn, since it's an
> implementation-specific detail and not a universal concept like int,
> point, or uuid.
If we're going to do that, I suggest pg_lsn rather than pglsn. We
already have pg_node_tree,
Robert Haas writes:
> It feels weird to me that the new columns are called transactionid and
> xmin. Why not xid and xmin?
Actually the part of that that bothers me is "xmin", which conflicts
with a reserved system column name. While you can legally pick such
conflicting names for view columns,
On Tue, Feb 4, 2014 at 11:43 PM, Noah Misch wrote:
>> Right. I mean, a lot of the links say things like "Section 26.2"
>> which obviously makes no sense in a standalone text file.
>
> For s normally displayed that way, text output could emit a URL, either
> inline or in the form of a footnote. F
On Tue, Feb 4, 2014 at 12:11 AM, Alvaro Herrera
wrote:
> I have run into some issues, though:
>
> 1. certain types, particularly timestamp/timestamptz but really this
> could happen for any type, have unusual typmod output behavior. For
> those one cannot just use the schema-qualified catalog nam
On Wed, Feb 5, 2014 at 11:48 AM, Tom Lane wrote:
> If we had infinite time/manpower, this wouldn't really be an issue.
> We don't, though, and so I suggest that this may be one of the better
> things to toss overboard.
The hstore send/recv functions have basically the same
(copy/pasted/name adjus
On Wed, Feb 5, 2014 at 7:21 AM, Andres Freund wrote:
> All current x86 processors use 64. But even if it were bigger/smaller,
> they will be either 32, or 128. Neither benefits from touching more
> cachelines than necessary. E.g. in the 128 case, we could still touch
> two with the current code.
On Wed, Feb 5, 2014 at 11:37 AM, Andres Freund wrote:
> On 2014-02-05 11:23:29 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
>> > just wasn't updated in the last 10 years.
>>
>> No, ALIGNOF_BUFFER is there because we r
On 02/05/2014 12:48 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/05/2014 11:40 AM, Tom Lane wrote:
switching to "binary is the same as text" may well be the most prudent
path here.
If we do that we're going to have to live with that forever, aren't we?
Yeah, but the other side of that c
On Mon, Feb 3, 2014 at 10:23 PM, Craig Ringer wrote:
Then during expansion of the range table, no code is needed to
ignore child rls quals and copy parent rels to child rels.
>>> This is what's already implemented and isn't a huge amount of code to
>>> begin with, so I don't see this as
Andrew Dunstan writes:
> On 02/05/2014 11:40 AM, Tom Lane wrote:
>> switching to "binary is the same as text" may well be the most prudent
>> path here.
> If we do that we're going to have to live with that forever, aren't we?
Yeah, but the other side of that coin is that we'll have to live for
On Mon, Feb 3, 2014 at 6:47 AM, Christian Kruse
wrote:
> [ new patch ]
Is there some compelling reason not to write the documentation link as
rather than using ?
It feels weird to me that the new columns are called transactionid and
xmin. Why not xid and xmin?
If I understand correctly, modif
On 02/05/2014 11:40 AM, Tom Lane wrote:
Merlin Moncure writes:
On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan wrote:
The whole reason we have jsonb is to avoid reparsing where possible
Sure; but on the server side. The wire format is for handling client
concerns. For example, the case yo
Merlin Moncure writes:
> On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan wrote:
>> The whole reason we have jsonb is to avoid reparsing where possible
> Sure; but on the server side. The wire format is for handling client
> concerns. For example, the case you're arguing for would be for libpq
On 2014-02-05 11:23:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
> > just wasn't updated in the last 10 years.
>
> No, ALIGNOF_BUFFER is there because we read something that said that I/O
> transfers between userspac
On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan wrote:
>> I'm actually surprised we have an alternate binary wire format for
>> jsonb at all; json is explicitly text and I'm not sure what the use
>> case of sending the internal structure is. Meaning, maybe jsonb
>> send/recv should be a thin wrap
Andres Freund writes:
> And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
> just wasn't updated in the last 10 years.
No, ALIGNOF_BUFFER is there because we read something that said that I/O
transfers between userspace and kernel disk cache would be faster with
aligned buffe
On 02/05/2014 10:36 AM, Teodor Sigaev wrote:
+Datum
+jsonb_typeof(PG_FUNCTION_ARGS)
+{
...
+}
Hm, shouldn't that be in jsonfuncs.c?
No idea, i don't have an objection
No it shouldn't. The json equivalent function is in json.c, and needs to
be because it uses the parser internals that
On 02/05/2014 10:48 AM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 12:44 AM, Heikki Linnakangas
wrote:
send/recv functions are also needed for binary-format COPY. IMHO jsonb must
have send/recv functions. All other built-in types have them, except for
types like 'smgr', 'aclitem' and 'any*'
On Wed, Feb 5, 2014 at 12:44 AM, Heikki Linnakangas
wrote:
> send/recv functions are also needed for binary-format COPY. IMHO jsonb must
> have send/recv functions. All other built-in types have them, except for
> types like 'smgr', 'aclitem' and 'any*' that no-one should be using as
> column type
+static void
+recvJsonbValue(StringInfo buf, JsonbValue *v, uint32 level, int c)
+ v->size = sizeof(JEntry) * 2 + VARSIZE_ANY(v->numeric);
What's the *2 here?
Reservation for aligment. It's allowed to be v->size greater than it's actually
needed. Fixed.
This function and recvJ
On Wed, Feb 5, 2014 at 8:50 PM, Heikki Linnakangas
wrote:
> On 02/05/2014 04:48 PM, Amit Kapila wrote:
>>
>> I have done one test where there is a large suffix match, but
>> not large enough that it can compress more than 75% of string,
>> the CPU overhead with wal-update-prefix-suffix-encode-1.pa
On 02/05/2014 04:48 PM, Amit Kapila wrote:
I have done one test where there is a large suffix match, but
not large enough that it can compress more than 75% of string,
the CPU overhead with wal-update-prefix-suffix-encode-1.patch is
not much, but there is no I/O reduction as well.
Hmm, it's sup
On Wed, Feb 5, 2014 at 5:13 PM, Heikki Linnakangas
wrote:
> On 02/05/2014 07:54 AM, Amit Kapila wrote:
>>
>> On Tue, Feb 4, 2014 at 11:58 PM, Robert Haas
>> wrote:
>>>
>>> On Tue, Feb 4, 2014 at 12:39 PM, Amit Kapila
>>> wrote:
Now there is approximately 1.4~5% CPU gain for
"hundr
On 2014-02-05 16:14:01 +0100, Greg Stark wrote:
> I see a lot of confusion online over whether cache lines
> are 64 bytes, 128 bytes, or other length even just on Intel
> architectures, let alone others.
All current x86 processors use 64. But even if it were bigger/smaller,
they will be either 32,
On Wed, Feb 5, 2014 at 3:57 PM, Tom Lane wrote:
> Maybe, or maybe not, but I think it does say that we should be very wary
> of proposals to force data structure alignment without any testing of the
> consequences.
Sure. see for instance
http://igoro.com/archive/gallery-of-processor-cache-effect
On 2014-02-05 09:57:11 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-02-04 16:24:02 -0800, Peter Geoghegan wrote:
> >> I suspect that the scenario described in this article accounts for the
> >> quite noticeable effect reported: http://danluu.com/3c-conflict
>
> > I don't think that'
Andres Freund writes:
> On 2014-02-04 16:24:02 -0800, Peter Geoghegan wrote:
>> I suspect that the scenario described in this article accounts for the
>> quite noticeable effect reported: http://danluu.com/3c-conflict
> I don't think that's applicable here.
Maybe, or maybe not, but I think it do
Heikki Linnakangas writes:
> On 02/02/2014 11:45 PM, Tom Lane wrote:
>> So I'm thinking my commit d2896a9ed, which introduced this mechanism,
>> was poorly thought out and we should just remove the relcache invals
>> as per the attached patch. Letting _bt_getroot() update the cached
>> metapage a
On Wed, Feb 5, 2014 at 5:29 PM, Heikki Linnakangas
wrote:
> On 01/30/2014 08:53 AM, Amit Kapila wrote:
>>
>> Is it possible to do for both prefix and suffix together, basically
>> the question I
>> have in mind is what will be deciding factor for switching from hash table
>> mechanism to string co
On 01/30/2014 08:53 AM, Amit Kapila wrote:
On Wed, Jan 29, 2014 at 8:13 PM, Heikki Linnakangas
wrote:
On 01/29/2014 02:21 PM, Amit Kapila wrote:
The main reason to process in chunks as much as possible is to save
cpu cycles. For example if we build hash table byte-by-byte, then even
for best c
On 02/05/2014 07:54 AM, Amit Kapila wrote:
On Tue, Feb 4, 2014 at 11:58 PM, Robert Haas wrote:
On Tue, Feb 4, 2014 at 12:39 PM, Amit Kapila wrote:
Now there is approximately 1.4~5% CPU gain for
"hundred tiny fields, half nulled" case
Assuming that the logic isn't buggy, a point in need of
On Sat, Feb 1, 2014 at 7:50 AM, Bruce Momjian wrote:
>
> Where are we on this?
I found myself to have empty draft letter from November with new version of
patch attached. I'll return here when we have some solution in gin fast
scan challenge.
--
With best regards,
Alexander Korotkov.
On Wed, Feb 5, 2014 at 1:23 AM, Alexander Korotkov wrote:
> On Mon, Feb 3, 2014 at 6:31 PM, Alexander Korotkov
> wrote:
>
>> On Mon, Jan 27, 2014 at 7:30 PM, Alexander Korotkov > > wrote:
>>
>>> On Mon, Jan 27, 2014 at 2:32 PM, Alexander Korotkov <
>>> aekorot...@gmail.com> wrote:
>>>
Every
On 02/04/2014 11:58 PM, Andres Freund wrote:
On February 4, 2014 10:50:10 PM CET, Peter Geoghegan wrote:
On Tue, Feb 4, 2014 at 11:11 AM, Andres Freund
wrote:
Does this feature relate to compression of WAL page images at all?
No.
So the obvious question is: where, if anywhere, do the two
On 02/02/2014 11:45 PM, Tom Lane wrote:
So I'm thinking my commit d2896a9ed, which introduced this mechanism,
was poorly thought out and we should just remove the relcache invals
as per the attached patch. Letting _bt_getroot() update the cached
metapage at next use should be a lot cheaper than
On 2014-02-04 16:24:02 -0800, Peter Geoghegan wrote:
> On Mon, Feb 3, 2014 at 3:38 PM, Andres Freund wrote:
> >> > A quick hack (attached) making BufferDescriptor 64byte aligned indeed
> >> > restored performance across all max_connections settings. It's not
> >> > surprising that a misaligned buf
On Tue, Feb 4, 2014 at 11:56 PM, Heikki Linnakangas
wrote:
>> Since, as I mentioned, _bt_finish_split() ultimately unlocks *and
>> unpins*, it may not be the same buffer as before, so even with the
>> refactoring there are race conditions.
>
> Care to elaborate? Or are you just referring to the mi
78 matches
Mail list logo
