Hi all,
On the recent following thread problems around the use of
AllocateDir() have been diagnosed with its use in the backend code:
https://www.postgresql.org/message-id/20171127093107.1473.70...@wrigleys.postgresql.org
I had a close look at all the callers of AllocateDir() and noticed a
couple
On Sat, Dec 2, 2017 at 12:41 AM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 10:04 AM, Chapman Flack wrote:
>> Can I call RegisterDynamicBackgroundWorker when not in the postmaster,
>> but also not in a "regular backend", but rather another BGW?
>
> I believe that doing it from another BGW works
Hi, Peter!
> 4 дек. 2017 г., в 4:55, Peter Geoghegan написал(а):
> Thoughts?
I like the idea of more compact B-tree.
Chances are that I didn't understood all your ideas.
But ItemId's let you insert a tuple among two existing tuples without data
movement. New tuple is places wherever free spac
On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire wrote:
> They did apply at the time, but I think major work on vacuum was
> pushed since then, and also I was traveling so out of reach.
>
> It may take some time to rebase them again. Should I move to needs
> review myself after that?
Sure, if you c
On Tue, Nov 28, 2017 at 10:37 PM, Michael Paquier
wrote:
> On Mon, Oct 2, 2017 at 11:02 PM, Claudio Freire
> wrote:
>> Rebased version of the patches attached
>
> The status of the patch is misleading:
> https://commitfest.postgresql.org/15/844/. This was marked as waiting
> on author but a new
On 04/12/17 16:08, Ashutosh Bapat wrote:
On Sun, Dec 3, 2017 at 5:56 AM, legrand legrand
wrote:
Hello,
I have a typical star schema, having dimension tables "product", "calendar"
and "country" and a fact table "sales".
This fact table is partitionned by time (range by month) and country (list
On Fri, Dec 1, 2017 at 8:04 PM, Robert Haas wrote:
> On Sun, Nov 26, 2017 at 3:15 AM, Amit Kapila wrote:
>> Yeah and I think something like that can happen after your patch
>> because now the memory for tuples returned via TupleQueueReaderNext
>> will be allocated in ExecutorState and that can la
On Sun, Dec 3, 2017 at 5:56 AM, legrand legrand
wrote:
> Hello,
>
> I have a typical star schema, having dimension tables "product", "calendar"
> and "country" and a fact table "sales".
> This fact table is partitionned by time (range by month) and country (list).
>
> Will query like:
>
> select p
On Wed, Nov 29, 2017 at 08:14:41PM -0800, Noah Misch wrote:
> 1. If $Config{gccversion} is nonempty, add _USE_32BIT_TIME_T. This will do
>the wrong thing if MinGW changes its default to match modern MSVC. It will
>do the wrong thing for a Perl built with "gcc -D__MINGW_USE_VC2005_COMPAT".
On Sat, Dec 2, 2017 at 4:08 AM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 7:41 AM, Ashutosh Bapat
> wrote:
>> This code creates plans where there are multiple Gather nodes under an Append
>> node.
>
> We should avoid that. Starting and stopping workers is inefficient,
> and precludes things li
On Sat, Dec 2, 2017 at 3:33 AM, Beena Emerson wrote:
> Append (cost=0.00..395.10 rows=9 width=8) (actual time=0.119..0.119
> rows=0 loops=1) (run-time partition pruning: on)
If we can, it would be better to show something a bit more precise,
like the table being used for run-time pruning, or th
On Sat, Dec 2, 2017 at 2:13 AM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 1:36 AM, Rajkumar Raghuwanshi
> wrote:
>> On Tue, Oct 31, 2017 at 2:45 PM, Robert Haas wrote:
OK, committed. This is a good example of how having good code
>>> coverage doesn't necessarily mean you've found all the
Hi,
I have rebased the patch on the latest version.
Because the CURRENT_DATABASE can not only being used on COMMENT ON
statement but also on other statements as following list so the patch name
is renamed to "support_CURRENT_DATABASE_keyword_vxx.patch".
1. COMMENT ON DATABASE CURRENT_DATABA
I've been working on adding a new feature to pg_hexedit [1] to allow
it to work with GIN indexes. This led to an idea about how we could do
better within nbtree, which I will now describe.
I noticed that GIN's internal posting tree pages (B-Trees over TIDs)
do away with the need for an ItemId arra
On Sat, Dec 2, 2017 at 1:11 AM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 12:21 AM, Michael Paquier
> wrote:
>> On Wed, Sep 13, 2017 at 4:07 PM, Ashutosh Bapat
>> wrote:
>>> For a partitioned table, this patch saves the time to run constraint
>>> exclusion on all the partitions if constraint e
I wrote:
> I tried creating multiple-column statistics using the v10 facility for
> that:
> regression=# create statistics s1 on num, flag from aaa;
> CREATE STATISTICS
> regression=# analyze aaa;
> ANALYZE
> but that changed the estimate not at all, which surprised me because
> dependency statisti
On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule wrote:
> I am not sure if user postgres should be removed, so it is probably bug
>
> pg_dumpall -r -c | grep postgres
>
> DROP ROLE postgres;
> CREATE ROLE postgres;
You are looking for this bit of code:
/*
* If asked
From: Tom Lane
It sounds like what you want is to replace all of Postgres except
the name. I'm not clear on the point.
The point is to make PostgreSQL a versatile database suitable even for
niche use cases. I want more people to love and rely on PostgreSQL.
Ideally, I want to see various data m
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 1, 2017 at 12:31 AM, Michael Paquier
> wrote:
> > I am moving this patch to next CF 2018-01.
>
> There now seems to be a consensus for superuser -> superuser_arg
> rather than what Jeff did originally; that approach has 4 vo
hi,
On Wed, Nov 29, 2017 at 8:00 AM, Peter Geoghegan wrote:
> On Tue, Nov 28, 2017 at 2:41 PM, Andres Freund wrote:
>> Maybe it's a stupid question. But would we still want to have this after
>> the change? These should be just specializations of the template version
>> imo.
"generic" version o
Robert Haas writes:
> But have a look at this:
> http://postgr.es/m/561e12d4.7040...@lab.ntt.co.jp
> That shows a case where, before
> 5fc4c26db5120bd90348b6ee3101fcddfdf54800, a query that required the
> foreign table to do an EPQ recheck produced an unambiguously wrong
> answer; the query stipul
Thomas Munro writes:
> So, in that plan we saw anti-join estimate 1 row but really there were
> 13462. If you remove most of Q21 and keep just the anti-join between
> l1 and l3, then you try removing different quals, you can see the the
> problem is not the <> qual:
> select count(*)
> fro
From: Henry
Would this require a the new pluggable storage which is currently in
development or would the existing storage engine be sufficient? I am
just wondering if there are any rough design/plans for this...
I'm sorry for the long interval. The graph model can be implemented
on top of the re
On Fri, Oct 13, 2017 at 7:59 AM, Ashutosh Bapat
wrote:
> On Thu, Oct 12, 2017 at 9:46 PM, Robert Haas wrote:
>> On Wed, Oct 11, 2017 at 7:08 AM, Ashutosh Bapat
>> wrote:
>>> Here's updated patch set based on the basic partition-wise join
>>> committed. The patchset applies on top of the patch to
The fact that the return type is not consistently of one type bothers
me. I'm not sure pgbench's expression language is a good place to
runtime polymorphism -- SQL doesn't work that way.
Sure.
Pg has a NUMERIC adaptative precision version, which is cheating, because it
can return kind of an
25 matches
Mail list logo
