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
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
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
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
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
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, 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
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
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
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 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'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
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
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
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 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 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 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 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 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 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 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
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 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 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
25 matches
Mail list logo
