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 as a RAM
> disk ju
В письме от 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 c
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
stored
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 compilation
> to native code should
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.
I
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 change type
> casting in BUCKETS_PER_PARTITION so that we are
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 c
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 does not update the ALTER TABL
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 add labels to an enum
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 be added as data is inserted.
>
> You realiz
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 predates our support
> for memory barriers, so "vola
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 I
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
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 d
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 betw
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 personally would say that
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 minor versions.
> In p
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 aroun
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 storage requirements as an enum, but instead of labels being
>>> declared ahead o
On Fri, Feb 2, 2018 at 12:39:28AM -0500, Bruce Momjian wrote:
> I just thought of an inconsistency. First, we now consistently exit with
> 'exit', 'quit', and '\q' if used in an empty psql query buffer. Also, we now
> hint when 'exit' and 'quit' are used in non-empty query buffers:
>
> te
Hi, hackers!Few years ago I've posted proposal [0] to improve GiST performance by building small GiST inside each GiST page.Currently each page is just an unordered vector of tuples. Scan is testing each tuple one by one. This causes suboptimal performance for both inserts and searches.I've attache
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 the *most*
> > appropriate behaviour? I
22 matches
Mail list logo
