Hello,
I updated the patch by taking ideas from your patch, and unifying the
transition struct and update function for different aggregates. The speed
of avg improved even more. It now has 60% better performance than the
current committed version.
This patch optimizes numeric/int8 sum, avg, stdde
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/19/2013 01:46 PM, Stephen Frost wrote:
> If you're using a public CA as your
> root, then you need to make sure you know how to ensure only the right
> people have access, typically be storing in the mapping table the unique
> ID issued by the C
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> They are intermediary, but we're dealing with the case where trust and
> authorization are not the same thing. Trust stems from the trusted root
> in the SSL CA model, but that's a chain of trust for *identity*
> (authentication), not *authori
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/18/2013 08:55 PM, Stephen Frost wrote:
> Makes sense to me. I'm not particular about the names, but isn't this
> set of CAs generally considered intermediary? Eg: 'trusted', '
> intermediate', etc?
They are intermediary, but we're dealing with t
On Wed, Mar 6, 2013 at 6:32 AM, Joachim Wieland wrote:
> On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
> wrote:
>> With these tweaks, I was able to make pglz-based delta encoding perform
>> roughly as well as Amit's patch.
>
> Out of curiosity, do we know how pglz compares with other algorit
On Mon, Mar 18, 2013 at 7:13 PM, Greg Smith wrote:
> I wasn't trying to flog EBS as any more or less reliable than other types of
> storage. What I was trying to emphasize, similarly to your "quite a
> stretch" comment, was the uncertainty involved when such deployments fail.
> Failures happen du
pg_basebackup and pg_receivexlog from 9.3 won't work with earlier
servers anymore. I wonder if this has been fully thought through. We
have put in a lot of effort to make client programs compatible with many
server versions as well as keeping the client/server protocol compatible
across many vers
On 2013.03.18 1:03 PM, Alvaro Herrera wrote:
For Dimitri's patch to add support for dropped objects in event
triggers, there's an open question about how to report objects that are
being dropped in a tabular format.
Now that JSON is a built-in type with 9.2+, could we not perhaps use that to
r
On 3/18/13 5:36 PM, Daniel Farina wrote:
Clarification, because I think this assessment as delivered feeds some
unnecessary FUD about EBS:
EBS is quite reliable. Presuming that all noticed corruptions are
strictly EBS's problem (that's quite a stretch), I'd say the defect
rate falls somewhere i
On Mon, Mar 18, 2013 at 12:08:09PM -0400, Steve Singer wrote:
> If you try running pg_upgrade with the PGSERVICE environment
> variable set to some invalid/non-existent service pg_upgrade
> segfaults
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0040bdd1 in check_pghost_envv
On Mon, Mar 18, 2013 at 1:31 PM, Greg Smith wrote:
> On 3/18/13 10:52 AM, Bruce Momjian wrote:
>>
>> With a potential 10-20% overhead, I am unclear who would enable this at
>> initdb time.
>
>
> If you survey people who are running PostgreSQL on "cloud" hardware, be it
> Amazon's EC2 or similar op
On Mon, Mar 18, 2013 at 2:04 AM, Greg Smith wrote:
> On 3/15/13 5:32 AM, Ants Aasma wrote:
>>
>> Best case using the CRC32 instruction would be 6.8 bytes/cycle [1].
>> But this got me thinking about how to do this faster...
>> [1]
>> http://www.drdobbs.com/parallel/fast-parallelized-crc-computatio
On Tue, Mar 19, 2013 at 8:54 AM, Michael Paquier
wrote:
>
>
> On Tue, Mar 19, 2013 at 3:03 AM, Fujii Masao wrote:
>
>> On Sun, Mar 17, 2013 at 9:24 PM, Michael Paquier
>> wrote:
>> > Please find attached the patches wanted:
>> > - 20130317_dump_only_valid_index.patch, a 1-line patch that makes
>>
On Tue, Mar 19, 2013 at 3:24 AM, Fujii Masao wrote:
> On Wed, Mar 13, 2013 at 9:04 PM, Michael Paquier
> wrote:
> > I have been working on improving the code of the 2 patches:
> > 1) reltoastidxid removal:
>
> > - Fix a bug with pg_dump and binary upgrade. One valid index is necessary
> > for a
On Tue, Mar 19, 2013 at 3:03 AM, Fujii Masao wrote:
> On Sun, Mar 17, 2013 at 9:24 PM, Michael Paquier
> wrote:
> > Please find attached the patches wanted:
> > - 20130317_dump_only_valid_index.patch, a 1-line patch that makes pg_dump
> > not take a dump of invalid indexes. This patch can be bac
Duh. Apologies. That's what happens when you make that 1 last change.
Please find an updated patch.
--
Robins Tharakan
On 19 March 2013 04:07, Josh Kupershmidt wrote:
> On Mon, Mar 18, 2013 at 3:10 PM, Robins Tharakan
> wrote:
> > Hi,
> >
> > Please find an updated patch (reworked on the nam
On Mon, Mar 18, 2013 at 3:10 PM, Robins Tharakan wrote:
> Hi,
>
> Please find an updated patch (reworked on the names of SEQUENCES / ROLES /
> SCHEMA etc.)
> Takes code-coverage of 'make check' for SEQUENCE to ~95%.
There is a typo difference between sequence.out and sequence.sql
causing the test
Tom Lane writes:
> I could also live with keeping the schema column as proposed, if people
> think it has a use, but letting it be redundant with a schema name
> included in the identity string. But it seems like a bad idea to try to
> shear schema off of identity.
+1
Use case for keeping the e
Hi,
Please find an updated patch (reworked on the names of SEQUENCES / ROLES /
SCHEMA etc.)
Takes code-coverage of 'make check' for SEQUENCE to ~95%.
--
Robins Tharakan
On 16 March 2013 02:03, robins wrote:
> Hi,
>
> I've added some regression tests for SEQUENCE. A cumulative patch is
> attac
On 03/18/2013 02:01 AM, Craig Ringer wrote:
> This appears to match Ian's description of having a validation-only cert
> list and a separate list of certs used to verify clients. I'd like to
> follow Apache's model:
Ready for some more good news?
It's possible that I'm missing something, but Apac
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> [ why not allow matviews to have OID columns? ]
>
>> An oid column in a materialized view will not be significantly more
>> stable than its ctid. The same "logical" row could easily have a
>> different OID on a REFRESH or even an i
Alvaro Herrera writes:
> For Dimitri's patch to add support for dropped objects in event
> triggers, there's an open question about how to report objects that are
> being dropped in a tabular format. What I proposed last had three
> columns: (type, schema, identity). The "type" is a description
Alvaro Herrera writes:
> For Dimitri's patch to add support for dropped objects in event
> triggers, there's an open question about how to report objects that are
> being dropped in a tabular format. What I proposed last had three
> columns: (type, schema, identity). The "type" is a description
On 3/18/13 10:52 AM, Bruce Momjian wrote:
With a potential 10-20% overhead, I am unclear who would enable this at
initdb time.
If you survey people who are running PostgreSQL on "cloud" hardware, be
it Amazon's EC2 or similar options from other vendors, you will find a
high percentage of them
On 03/18/2013 12:29 PM, Andrew Dunstan wrote:
>
> One wrinkle in this picture is the variadic forms of extraction which
> don't lend themselves nicely to use with an operator. We could decide to
> do away with those altogether, or come up with a better name. I'm loath
> to use "json_path" since it
Andrew Dunstan writes:
> I've been sitting here for a while mulling none too happily over the
> debate on the names for the proposed JSON extraction functions. I
> haven't really been happy with any of the suggestions, much, not least
> my own original function names which were really only inte
For Dimitri's patch to add support for dropped objects in event
triggers, there's an open question about how to report objects that are
being dropped in a tabular format. What I proposed last had three
columns: (type, schema, identity). The "type" is a description of the
object class; I propose t
Kevin Grittner writes:
> Tom Lane wrote:
>> [ why not allow matviews to have OID columns? ]
> An oid column in a materialized view will not be significantly more
> stable than its ctid. The same "logical" row could easily have a
> different OID on a REFRESH or even an incremental update (due to
On 03/01/2013 11:09 AM, Merlin Moncure wrote:
On Fri, Feb 22, 2013 at 11:50 AM, David E. Wheeler
wrote:
On Feb 22, 2013, at 9:37 AM, Robert Haas wrote:
What I think is NOT tolerable is choosing a set of short but arbitrary
names which are different from anything that we have now and
pretend
On 18 March 2013 19:02, Jeff Davis wrote:
> On Sun, 2013-03-17 at 22:26 -0700, Daniel Farina wrote:
>> as long as I am able to turn them off easily
>
> To be clear: you don't get the performance back by doing
> "ignore_checksum_failure = on". You only get around the error itself,
> which allows yo
On Fri, Mar 15, 2013 at 05:47:30PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I'm marking this patch Ready for Committer, qualified with a recommendation
> > to
> > adopt only the wal.sgml changes.
>
> I've committed this along with some further wordsmithing. I kept
> Peter's change to pg_
On Mon, Mar 18, 2013 at 06:24:37PM +, Simon Riggs wrote:
> On 18 March 2013 17:52, Bruce Momjian wrote:
> > On Sun, Mar 17, 2013 at 05:50:11PM -0700, Greg Smith wrote:
> >> As long as the feature is off by default, so that people have to
> >> turn it on to hit the biggest changed code paths, t
On Mon, Mar 18, 2013 at 11:42:23AM -0700, Jeff Davis wrote:
> On Mon, 2013-03-18 at 13:52 -0400, Bruce Momjian wrote:
> > In fact, this feature is going to need
> > pg_upgrade changes to detect from pg_controldata that the old/new
> > clusters have the same checksum setting.
>
> I believe that has
On Sun, 2013-03-17 at 22:26 -0700, Daniel Farina wrote:
> as long as I am able to turn them off easily
To be clear: you don't get the performance back by doing
"ignore_checksum_failure = on". You only get around the error itself,
which allows you to dump/reload the good data.
Regards,
Je
On Mon, 2013-03-18 at 13:52 -0400, Bruce Momjian wrote:
> In fact, this feature is going to need
> pg_upgrade changes to detect from pg_controldata that the old/new
> clusters have the same checksum setting.
I believe that has been addressed in the existing patch. Let me know if
you see any proble
Tom Lane wrote:
> I wrote:
>> BTW, is there a really solid reason why a matview couldn't be
>> allowed to have OIDs on demand, and thereby dodge this whole
>> problem? I'm thinking that the analogy to regular views not
>> having OIDs is not a very good argument, because certainly
>> matview rows
> With a potential 10-20% overhead, I am unclear who would enable this at
> initdb time.
People who know they have a chronic issue with bad disks/cards/drivers
would. Or anyone with enough machines that IO corruption is an
operational concern worth more than 10% overhead.
Or, in a word: Heroku,
* Bruce Momjian (br...@momjian.us) wrote:
> With a potential 10-20% overhead, I am unclear who would enable this at
> initdb time.
I'd expect that quite a few people would, myself included on a brand new
DB that I didn't have any reason to think would need to be
super-performant.
> I assume a use
On 18 March 2013 17:52, Bruce Momjian wrote:
> On Sun, Mar 17, 2013 at 05:50:11PM -0700, Greg Smith wrote:
>> As long as the feature is off by default, so that people have to
>> turn it on to hit the biggest changed code paths, the exposure to
>> potential bugs doesn't seem too bad. New WAL data
On Wed, Mar 13, 2013 at 9:04 PM, Michael Paquier
wrote:
> I have been working on improving the code of the 2 patches:
> 1) reltoastidxid removal:
> - Fix a bug with pg_dump and binary upgrade. One valid index is necessary
> for a given toast relation.
Is this bugfix related to the following?
2013/3/18 Bruce Momjian :
> On Sun, Mar 17, 2013 at 05:50:11PM -0700, Greg Smith wrote:
>> As long as the feature is off by default, so that people have to
>> turn it on to hit the biggest changed code paths, the exposure to
>> potential bugs doesn't seem too bad. New WAL data is no fun, but
>> it
On Sun, Mar 17, 2013 at 9:24 PM, Michael Paquier
wrote:
> Please find attached the patches wanted:
> - 20130317_dump_only_valid_index.patch, a 1-line patch that makes pg_dump
> not take a dump of invalid indexes. This patch can be backpatched to 9.0.
Don't indisready and indislive need to be chec
On 03/13/2013 09:54 AM, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
>> At run time, this will sort itself out, because all the required modules
>> will be loaded. The problem is when you create the "glue" extension and
>> haven't invoked any code from any of the dependent extension in the
On Sun, Mar 17, 2013 at 05:50:11PM -0700, Greg Smith wrote:
> As long as the feature is off by default, so that people have to
> turn it on to hit the biggest changed code paths, the exposure to
> potential bugs doesn't seem too bad. New WAL data is no fun, but
> it's not like this hasn't happened
I wrote:
> BTW, is there a really solid reason why a matview couldn't be allowed to
> have OIDs on demand, and thereby dodge this whole problem? I'm thinking
> that the analogy to regular views not having OIDs is not a very good
> argument, because certainly matview rows are going to need all the
If you try running pg_upgrade with the PGSERVICE environment variable
set to some invalid/non-existent service pg_upgrade segfaults
Program received signal SIGSEGV, Segmentation fault.
0x0040bdd1 in check_pghost_envvar () at server.c:304
304 for (option = start; option->keywo
Hello
I played with sum(numeric) optimization
Now it is based on generic numeric_add function - this code is
relative old - now we can design aggregates with internal transition
buffers, and probably we can do this work more effective.
I just removed useles palloc/free operations and I got a 30%
Alvaro Herrera writes:
> Here's a rebased version; there were some merge conflicts with master.
Thanks!
> I also fixed some compiler warnings. I haven't reviewed the patch in
> any detail yet. One thing that jump at me from the code style
> perspective is the strange way it deals with "isnull"
Boszormenyi Zoltan writes:
> How about the attached patch over current GIT? In other words,
> why I am wrong with this idea?
Because it's wrong. Removing "volatile" means that the compiler is
permitted to optimize away stores (and fetches!) on the basis of their
being unnecessary according to st
On 18 March 2013 00:50, Greg Smith wrote:
> On 3/17/13 1:41 PM, Simon Riggs wrote:
>>
>> So I'm now moving towards commit using a CRC algorithm. I'll put in a
>> feature to allow algorithm be selected at initdb time, though that is
>> mainly a convenience to allow us to more easily do further tes
Craig, all,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> PROBLEM VERIFIED
Let me just say "ugh". I've long wondered why we have things set up in
such a way that the whole chain has to be in one file, but it didn't
occur to me that it'd actually end up causing this issue. In some ways,
I real
Hi,
Attached is an updated patch that uses better schema / role names.
--
Robins Tharakan
On 18 March 2013 12:59, robins wrote:
> Thanks Alvaro.
>
> Since the tests were running fine, I didn't bother with elaborate names,
> but since you're concerned guess I'll make that change and re-submit.
2013-03-18 06:47 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
The volatile marking shouldn't even be necessary there.
The signal handler doesn't writes to it, only the main code.
Well, (a) that's not the case in the patch as committed, and (b) even if
it were true, the volatile marki
Hi Pavel,
Thanks a lot for your feedback.
I'll work more on this patch this week, and will send a more complete patch
later this week.
I'll also try to see how much is the speed up of this method for other
types.
Thanks,
-- Hadi
On Mon, Mar 18, 2013 at 10:36 AM, Pavel Stehule wrote:
> 2013/
2013/3/16 Hadi Moshayedi :
> Revisiting:
> http://www.postgresql.org/message-id/45661be7.4050...@paradise.net.nz
>
> I think the reasons which the numeric average was slow were:
> (1) Using Numeric for count, which is slower than int8 to increment,
> (2) Constructing/deconstructing arrays at ea
Thanks Alvaro.
Since the tests were running fine, I didn't bother with elaborate names,
but since you're concerned guess I'll make that change and re-submit.
And yes, I've already submitted (to Commitfest) another patch related to
regression tests for SEQUENCE.
Would submit the SCHEMA patch once
On 03/18/2013 02:27 PM, Ian Pilcher wrote:
> On 03/18/2013 12:07 AM, Craig Ringer wrote:
>> So this problem is verified.
> * Trusted certificates - What currently goes in the (unfortunately
> named) root.crt file.
Well, a little unfortunate. It contains roots of *client authentication*
trust, w
On 03/18/2013 01:07 PM, Craig Ringer wrote:
> System wide installation of the root may allow OpenSSL to discover it
> and use it for verification back to the root without having to trust it
> to sign clients. I'll do some more checking to see if this is possible
> with how Pg uses OpenSSL but I'm i
58 matches
Mail list logo
