Re: Is there a cache consistent interface to tables ?

On 11 February 2018 at 04:44, Gary M wrote: > Thanks Craig, > > As I'm back in pg code after many years, I'm feeling much better there's > one (1) or two (2) items causing the hiccup. Rereading your comments, I'm > agreeing with you. I'm considering bumping up the ram to 512gb

Re: [PATCH][PROPOSAL] Add enum releation option type

В письме от 9 февраля 2018 18:45:29 пользователь Alvaro Herrera написал: > If this patch gets in, I wonder if there are any external modules that > use actual strings. An hypothetical example would be something like a > SSL cipher list; it needs to be somewhat free-form that an enum would > not

Re: JIT compiling with LLVM v9.0

On Thu, Jan 25, 2018 at 9:40 AM, Konstantin Knizhnik wrote: > As far as I understand generation of native code is now always done for all > supported expressions and individually by each backend. > I wonder it will be useful to do more efforts to understand when

Re: [HACKERS] generated columns

On Thu, Feb 01, 2018 at 09:29:09AM -0500, Peter Eisentraut wrote: > That would be nice. I'm going to study this some more to see what can > be done. By the way, cannot we consider just doing stored generated columns as a first cut? Both virtual and stored columns have their use cases, but

persistent read cache

Hi. I wonder if there is such a thing or extension in the PG world. Here is my use case. I am using PG (PG10 to be more specific) in a cloud VM environment. The tables are stored in RAID0 managed SSD backed attached storage. Depending on the VM I am using, I usually have 256GB local SSD unused.

Re: [HACKERS] Fix warnings and typo in dshash

On Mon, Sep 4, 2017 at 2:18 PM, Amit Kapila wrote: > On Sun, Sep 3, 2017 at 2:56 PM, Thomas Munro > wrote: >> I think it should be (size_t) 1, not UINT64CONST(1). See attached. > > Okay, that makes sense. Do you think we should also

Re: ALTER TABLE ADD COLUMN fast default

On Sun, Feb 11, 2018 at 2:50 PM, Petr Jelinek wrote: >> >> >> Here's a version that fixes the above issue and also the issue with >> VACUUM that Tomas Vondra reported. I'm still working on the issue with >> aggregates that Tomas also reported. >> > > I see the patch

A space-efficient, user-friendly way to store categorical data

Hi, I'm hoping to get feedback on an idea for a new data type to allow for efficient storage of text values while keeping reads and writes user-friendly. Suppose you want to store categorical data like current city for users. There will be a long list of cities, and many users will have the same

Re: A space-efficient, user-friendly way to store categorical data

Andrew Kane writes: > A better option could be a new "dynamic enum" type, which would have > similar storage requirements as an enum, but instead of labels being > declared ahead of time, they would be added as data is inserted. You realize, of course, that it's possible to

OCD questions about LWTRANCHE_REPLICATION_ORIGIN

Hi, Just curious about a harmless inconsistency, really: why does src/backend/replication/logical/origin.c bother to copy LWTRANCHE_REPLICATION_ORIGIN into shm and then LWLockRegisterTranche() in every process from the shm copy? I guess because it used to allocate the tranche ID dynamically with

Re: A space-efficient, user-friendly way to store categorical data

On Mon, Feb 12, 2018 at 9:10 AM, Tom Lane wrote: > Andrew Kane writes: >> A better option could be a new "dynamic enum" type, which would have >> similar storage requirements as an enum, but instead of labels being >> declared ahead of time, they would

Re: [HACKERS] A misconception about the meaning of 'volatile' in GetNewTransactionId?

On Sun, Apr 30, 2017 at 1:19 PM, Tom Lane wrote: > Thomas Munro writes: >> I was reading xact.c and noticed this block: >> ... >> Isn't this insufficient on non-TSO systems like POWER and Arm? > > Yeah, I think you're right. That code probably

Removing shm_mq.c's volatile qualifiers

Hi, As far as I can see, all the volatile qualifiers in shm_mq.c have been redundant since ec9037df263. Here's a patch to remove them (like several similar patches -- see commit message). Does this make sense? Is there something special about that pointer to volatile pointer to PGPROC? If so

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Feb 9, 2018 at 6:53 AM, Peter Geoghegan wrote: > On Wed, Feb 7, 2018 at 7:51 PM, Pavan Deolasee > wrote: > > I understand getting EPQ semantics right is very important. Can you > please > > (once again) summarise your thoughts on what you think is

Re: A space-efficient, user-friendly way to store categorical data

On Mon, Feb 12, 2018 at 12:24 PM, Andrew Dunstan wrote: > On Mon, Feb 12, 2018 at 9:10 AM, Tom Lane wrote: >> Andrew Kane writes: >>> A better option could be a new "dynamic enum" type, which would have >>> similar

Minor version upgrades and extension packaging

Hi All, I am writing to get some advice on extension packaging for minor version upgrades in Postgres. We recently found that people who had compiled the TimescaleDB extension against 10.1 (or installed our binary versions via yum, apt, etc.) had their extension break when they upgraded to 10.2

Re: Minor version upgrades and extension packaging

Andres Freund writes: > On 2018-02-11 21:50:32 -0500, Mat Arye wrote: >> In particular, in the commit >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1597948c962a1407c01fc492c44917c097efa92e >> the structure of the ColumnDef struct changed. > Ugh. I

Re: Minor version upgrades and extension packaging

Mat Arye writes: > We recently found that people who had compiled the TimescaleDB extension > against 10.1 (or installed our binary versions via yum, apt, etc.) had > their extension break when they upgraded to 10.2 due to changes of some > underlying structs between the two

Re: Minor version upgrades and extension packaging

On 2018-02-11 22:19:30 -0500, Tom Lane wrote: > Not sure what to do about it at this point. We could move that field to > the end for 10.3, leaving 10.2 as the only ABI-incompatible minor release, > but I don't know that that really makes things any better than leaving it > as-is. Somewhere

Re: Minor version upgrades and extension packaging

Hi, On 2018-02-11 21:50:32 -0500, Mat Arye wrote: > We recently found that people who had compiled the TimescaleDB extension > against 10.1 (or installed our binary versions via yum, apt, etc.) had > their extension break when they upgraded to 10.2 due to changes of some > underlying structs