Re: [HACKERS] Add Roman numeral conversion to to_number

2017-09-19 Thread Doug Doole
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Applied clean and runs fine. Previous comments were

Re: [HACKERS] Add Roman numeral conversion to to_number

2017-09-14 Thread Doug Doole
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Code looks fine, but one niggly complaint at line 146 of the patch

Re: [HACKERS] Small code improvement for btree

2017-09-14 Thread Doug Doole
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested Looks good to me. The new status of this patch is: Ready for

Re: [HACKERS] Cached plans and statement generalization

2017-04-26 Thread Doug Doole
> > A naive option would be to invalidate anything that depends on table or > view *.FOOBAR. You could probably make it a bit smarter by also requiring > that schema A appear in the path. > This has been rumbling around in my head. I wonder if you could solve this problem by registering

Re: [HACKERS] Cached plans and statement generalization

2017-04-25 Thread Doug Doole
> > (FWIW, on this list we don't do top-quotes) > I know. Forgot and just did "reply all". My bad. It's not always that simple, at least in postgres, unless you disregard > search_path. Consider e.g. cases like > > CREATE SCHEMA a; > CREATE SCHEMA b; > CREATE TABLE a.foobar(somecol int); > SET

Re: [HACKERS] Cached plans and statement generalization

2017-04-25 Thread Doug Doole
RU for cache memory management of course). With literal replacement, the cache entry is on the modified statement text. Given the modified statement text and the compilation environment, you're guaranteed to get the right plan entry. On Tue, Apr 25, 2017 at 2:47 PM Andres Freund <and...@anarazel.de>

Re: [HACKERS] Cached plans and statement generalization

2017-04-25 Thread Doug Doole
When I did this in DB2, I didn't use the parser - it was too expensive. I just tokenized the statement and used some simple rules to bypass the invalid cases. For example, if I saw the tokens "ORDER" and "BY" then I'd disallow replacement replacement until I hit the end of the current subquery or

Re: [HACKERS] Improving executor performance

2016-11-07 Thread Doug Doole
the latest and greatest? If not, any chance of getting the latest? Going forward, I'd be happy to collaborate on our efforts. - Doug Doole Salesforce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Improving executor performance

2016-11-04 Thread Doug Doole
tackle that, is the posted proof-of-concept still the latest and greatest? If not, any chance of getting the latest? Going forward, I'd like to collaborate on our efforts if you're interested. - Doug Doole Salesforce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] ICU integration

2016-09-07 Thread Doug Doole
strcmp()/memcmp() was never called for user data. (I don't know if the same can be said for Postgres.) We found that very few places needed to be aware of values that were equal but not identical. (Index and sort were the big two.) Hopefully Postgres will be the same. -- Doug Doole

Re: [HACKERS] ICU integration

2016-09-07 Thread Doug Doole
d support for every drop of ICU.) On Wed, Sep 7, 2016 at 5:53 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 9/6/16 1:40 PM, Doug Doole wrote: > > We carried the ICU version numbers around on our collation and locale > > IDs (such as fr_FR%icu36) . The databas

Re: [HACKERS] ICU integration

2016-09-06 Thread Doug Doole
ger qualify in the database. It could be argued that these are edge cases and not likely to be hit. That's likely true for a lot of users. But for a user who hits this, their database is going to be left in a mess. -- Doug Doole On Tue, Sep 6, 2016 at 8:37 AM Peter Eisentraut < peter.eisentr

Re: [HACKERS] ICU integration

2016-08-31 Thread Doug Doole
he database can become inconsistent and will need a lot more work than an index rebuild. > Suggestions for refining this are welcome. > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services