Hi Rajkumar,
On Fri, Sep 16, 2016 at 6:00 PM, Rajkumar Raghuwanshi
wrote:
>
> On Fri, Sep 9, 2016 at 3:17 PM, Ashutosh Bapat
> wrote:
>>
>> Hi All,
>>
>> PFA the patch to support partition-wise joins for partitioned tables. The
>> patch
>> is based on the declarative parition support patches pr
Hi,
I got a server crash with partition_wise_join, steps to reproduce given
below.
postgres=# set enable_partition_wise_join=true;
SET
postgres=# CREATE TABLE tbl (a int,c text) PARTITION BY LIST(a);
CREATE TABLE
postgres=# CREATE TABLE tbl_p1 PARTITION OF tbl FOR VALUES IN (1, 2);
CREATE TABLE
p
On Sat, Sep 17, 2016 at 2:04 AM, Masahiko Sawada wrote:
> Since we already released 9.6RC1, I understand that it's quite hard to
> change syntax of 9.6.
> But considering that we support the quorum commit, this could be one
> of the solutions in order to avoid breaking backward compatibility and
>
Hello,
At Tue, 13 Sep 2016 11:44:01 +0300, Heikki Linnakangas wrote
in <7ff67a45-a53e-4d38-e25d-3a121afea...@iki.fi>
> On 09/08/2016 09:35 AM, Kyotaro HORIGUCHI wrote:
> > Returning in UTF-8 bloats the result string by about 1.5 times so
> > it doesn't seem to make sense comparing with it. But i
On Wed, Sep 21, 2016 at 3:25 AM, Jesper Pedersen
wrote:
> On 09/20/2016 12:45 PM, Jeff Janes wrote:
>> Is the 2nd "1" in this call needed?
>>
>> SELECT * FROM hash_page_stats(get_raw_page('mytab_index', 1), 1)
>>
>> As far as I can tell, that argument is only used to stuff into the output
>> field
On Wed, Sep 21, 2016 at 3:48 AM, Tomas Vondra
wrote:
>
> I have no idea what's causing this - it might be related to the kernel, but
> I'm not sure why it should affect the patches differently. Let's see how the
> new kernel affects this.
>
> dilip / sync=off 16 32 64 128
On Tue, Sep 20, 2016 at 10:24 PM, Jeff Janes wrote:
> On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila
> wrote:
>>
>>
>> Okay, Thanks for pointing out the same. I have fixed it. Apart from
>> that, I have changed _hash_alloc_buckets() to initialize the page
>> instead of making it completely Zero
On Tue, Sep 20, 2016 at 4:32 PM, valeriof wrote:
> Hi Ashutosh,
> Thank you for your answer. At the end I realized that the PGDLLEXPORT
> keyword was missing from the functions definitions.
>
> As a side question, what are the options to debug the plugin while it's
> being executing? I've seen a d
On Wed, Sep 21, 2016 at 1:03 PM, Thomas Munro
wrote:
> Yeah but that's at run time. I meant you could help developers
> discover ASAP if they add a new item to one place but not the other
> with a compile time assertion:
> const char *
> GetWaitEventIdentifier(uint16 eventId)
> {
>
On Wed, Sep 21, 2016 at 3:40 PM, Michael Paquier
wrote:
> On Wed, Sep 21, 2016 at 8:13 AM, Thomas Munro
> wrote:
>> It looks like this array wants to be in alphabetical order, but it
>> isn't quite. Also, perhaps a compile time assertion about the size of
>> the array matching EVENT_LAST_TYPE co
On Wed, Sep 21, 2016 at 8:13 AM, Thomas Munro
wrote:
> +
> + EventSet: The server process is waiting on a socket
> + or a timer. This wait happens in a latch, an inter-process facility
> + using boolean variables letting a process sleep until it is set.
> +
On Tue, 20 Sep 2016, Peter Eisentraut wrote:
On 9/18/16 4:17 PM, Steve Singer wrote:
I think if we want to prevent the creation of subscriptions that point
to self, then we need to create a magic token when the postmaster starts
and check for that when we connect. So more of a running-insta
On Tue, Sep 20, 2016 at 9:15 AM, Dilip Kumar wrote:
> +1
>
> My test are under run, I will post it soon..
I have some more results now
8 socket machine
10 min run(median of 3 run)
synchronous_commit=off
scal factor = 300
share buffer= 8GB
test1: Simple update(pgbench)
Clients Head
On Wed, Sep 21, 2016 at 10:25 AM, Michael Paquier
wrote:
> On Wed, Sep 21, 2016 at 12:32 AM, Robert Haas wrote:
>> For what it's worth, I think it's fine. Good error messages are a useful
>> thing.
>>
>> More generally, I think the whole patch looks good and should be committed.
>
> Hm. I'd thi
On Thu, Sep 15, 2016 at 6:01 AM, Robert Haas wrote:
> On Fri, Sep 2, 2016 at 2:33 AM, Haribabu Kommi
> wrote:
> > On Wed, Aug 31, 2016 at 3:19 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
> >> Haribabu Kommi wrote:
> >>
> >>> Apart from the above, here are the following list of co
On Wed, Sep 21, 2016 at 12:32 AM, Robert Haas wrote:
> For what it's worth, I think it's fine. Good error messages are a useful
> thing.
>
> More generally, I think the whole patch looks good and should be committed.
Hm. I'd think that it is still more portable to just issue a WARNING
message i
2016-09-20 18:35 GMT+02:00, Tom Lane :
> Rudolf Gavlas writes:
>> The usage of HOME environment variable (if set) is IMO the right,
>> standard and faster way to get_home_path().
>
> Can you provide some evidence for that claim? I can believe "faster"
> but the rest sounds like wishful thinking.
2016-09-20 18:55 GMT+02:00, Alvaro Herrera :
> Rudolf Gavlas wrote:
>
>> I work in an environment, where servers are administered by people
>> with different user names and identical uid (0).
>
> So everyone is superuser there? That sounds, um, unorthodox.
Yes, the administrators of the servers,
On 9/19/16 3:23 PM, Michael Banck wrote:
> Version 2 attached.
Committed, thanks.
I added the new option to the help output in pg_restore.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hack
On Mon, Sep 19, 2016 at 03:50:38PM -0400, Robert Haas wrote:
> It will probably have some bugs, but they probably won't be worse than
> the status quo:
>
> WARNING: hash indexes are not WAL-logged and their use is discouraged
>
> Personally, I think it's outright embarrassing that we've had that
On 09/02/2016 11:01 AM, Robert Haas wrote:
On Fri, Sep 2, 2016 at 8:49 AM, Andres Freund wrote:
On 2016-09-02 08:31:42 +0530, Robert Haas wrote:
I wonder whether we ought to just switch from the consistent method to
the semiconsistent method and call it good.
+1. I think, before long, we're
On 09/05/2016 06:19 PM, Ivan Kartyshov wrote:
On 09/03/2016 05:04 AM, Tomas Vondra wrote:
This patch needs a rebase, as 06d7fd6e bumped the version to 1.2.
Thank you for a valuable hint.
So, will we get a rebased patch? I see the patch is back in 'needs
review' but there's no new version.
+
+ EventSet: The server process is waiting on a socket
+ or a timer. This wait happens in a latch, an inter-process facility
+ using boolean variables letting a process sleep until it is set.
+ Latches support several type of operations, like postmaster
Hi,
On 09/19/2016 09:10 PM, Robert Haas wrote:
>
It's possible that the effect of this patch depends on the number of
sockets. EDB test machine cthulhu as 8 sockets, and power2 has 4
sockets. I assume Dilip's tests were run on one of those two,
although he doesn't seem to have mentioned which on
> On Sep 20, 2016, at 1:06 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Would patches to not cast away const be considered?
>
> In general, yes, but I'm not especially in favor of something like this:
>
>> bool
>> PageIndexTupleOverwrite(Page page, OffsetNumber offnum,
>> -
Mark Dilger writes:
> Friends, per the recent thread "gratuitous casting away const", the
> assignment on line 1247 of localtime.c has const lvalue and rvalue,
> yet casts through (char *) rather than (const char *). Fix attached.
If you want to propose cosmetic improvements in localtime.c, or t
Friends, per the recent thread "gratuitous casting away const", the
assignment on line 1247 of localtime.c has const lvalue and rvalue,
yet casts through (char *) rather than (const char *). Fix attached.
Mark Dilger
localtime.c.patch
Description: Binary data
--
Sent via pgsql-hackers mailin
On 2016-09-20 16:32:46 -0400, Robert Haas wrote:
> > Requiring a non-default compile time or even just cluster creation time
> > option for tuning isn't something worth expanding energy on imo.
>
> I don't agree. The latency requirements on an archive_command when
> you're churning out 16MB files
On Tue, Sep 20, 2016 at 4:25 PM, Andres Freund wrote:
>> Even with a 1GB segment size, some of them will fill multiple files
>> per minute. At the current limit of 64MB, a few of them would still
>> fill more than one file per second. That is not sane.
>
> I doubt generating much larger files ac
On 2016-09-20 16:18:02 -0400, Robert Haas wrote:
> On Tue, Sep 20, 2016 at 4:09 PM, Andres Freund wrote:
> > That sounds way too big to me. WAL file allocation would trigger pretty
> > massive IO storms during zeroing, max_wal_size is going to be hard to
> > tune, the amounts of dirty data during
On Tue, Sep 20, 2016 at 4:09 PM, Andres Freund wrote:
> On 2016-09-20 16:05:44 -0400, Robert Haas wrote:
>> On Tue, Sep 20, 2016 at 2:49 PM, Peter Eisentraut
>> wrote:
>> > On 8/24/16 9:31 PM, Robert Haas wrote:
>> >> I'd like to propose that we increase the default WAL segment size,
>> >> which
On 2016-09-20 16:05:44 -0400, Robert Haas wrote:
> On Tue, Sep 20, 2016 at 2:49 PM, Peter Eisentraut
> wrote:
> > On 8/24/16 9:31 PM, Robert Haas wrote:
> >> I'd like to propose that we increase the default WAL segment size,
> >> which is currently 16MB.
> >
> > While the discussion about the best
On Tue, Sep 20, 2016 at 3:31 PM, Peter Eisentraut
wrote:
> On 9/20/16 11:47 AM, Robert Haas wrote:
>> #define BGWORKER_CLASS_MASK 0x00f0
>> #define BGWORKER_CLASS_PARALLEL 0x0010
>> /* add additional bgworker classes here */
>>> >
>>> > Unless we have a mechanism that makes use o
Mark Dilger writes:
> Would patches to not cast away const be considered?
In general, yes, but I'm not especially in favor of something like this:
> bool
> PageIndexTupleOverwrite(Page page, OffsetNumber offnum,
> - Item newtup, Size newsize)
> +
On Tue, Sep 20, 2016 at 2:49 PM, Peter Eisentraut
wrote:
> On 8/24/16 9:31 PM, Robert Haas wrote:
>> I'd like to propose that we increase the default WAL segment size,
>> which is currently 16MB.
>
> While the discussion about the best default value is ongoing, maybe we
> should at least *allow* s
Friends,
There are places in the code that cast away const for no apparent
reason, fixed like such:
diff --git a/src/backend/executor/nodeIndexscan.c
b/src/backend/executor/nodeIndexscan.c
index 3143bd9..fe2cfc2 100644
--- a/src/backend/executor/nodeIndexscan.c
+++ b/src/backend/executor/nodeI
On 9/20/16 11:47 AM, Robert Haas wrote:
>>> >> #define BGWORKER_CLASS_MASK 0x00f0
>>> >> #define BGWORKER_CLASS_PARALLEL 0x0010
>>> >> /* add additional bgworker classes here */
>> >
>> > Unless we have a mechanism that makes use of this somehow, this attempt
>> > at categorizing might be premat
On 9/20/16 3:04 PM, David Fetter wrote:
> On Fri, Sep 09, 2016 at 09:57:21AM -0400, Peter Eisentraut wrote:
>> Review of the patch in the commit fest:
>>
>> - The documentation is a bit incorrect about the ways to load this
>> module. shared_preload_libraries is not necessary. session_ and
>>
On Fri, Sep 09, 2016 at 09:57:21AM -0400, Peter Eisentraut wrote:
> Review of the patch in the commit fest:
>
> - The documentation is a bit incorrect about the ways to load this
> module. shared_preload_libraries is not necessary. session_ and
> local_ (with prep) should also work.
Would y
Rudolf Gavlas wrote:
> 2016-09-20 18:55 GMT+02:00, Alvaro Herrera :
> > Rudolf Gavlas wrote:
> >
> >> I work in an environment, where servers are administered by people
> >> with different user names and identical uid (0).
> >
> > So everyone is superuser there? That sounds, um, unorthodox.
>
> Y
Why not use generate_series() queries to insert the appropriate number
of tuples, instead of a handful of INSERT lines each time? Since each
insert is a separate transaction, that would probably be faster.
Why do you have a plpgsql function just to create a cursor? Wouldn't it
be simpler to cre
On 8/24/16 9:31 PM, Robert Haas wrote:
> I'd like to propose that we increase the default WAL segment size,
> which is currently 16MB.
While the discussion about the best default value is ongoing, maybe we
should at least *allow* some larger sizes, for testing out. Currently,
configure says "Allo
On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire wrote:
> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote:
>>
>> Claudio, if you could also repeat the tests you ran on Peter's patch set on
>> the other thread, with these patches, that'd be nice. These patches are
>> effectively a replaceme
On 09/16/2016 02:42 AM, Amit Kapila wrote:
Okay, Thanks for pointing out the same. I have fixed it. Apart from
that, I have changed _hash_alloc_buckets() to initialize the page
instead of making it completely Zero because of problems discussed in
another related thread [1]. I have also updated
Hi,
On 09/20/2016 01:46 PM, Ashutosh Sharma wrote:
I am getting a fatal error along with some warnings when trying to
apply the v3 patch using "git apply" command.
[ashu@localhost postgresql]$ git apply
0001-pageinspect-Hash-index-support_v3.patch
0001-pageinspect-Hash-index-support_v3.patch:29
On 09/20/2016 12:45 PM, Jeff Janes wrote:
Is the 2nd "1" in this call needed?
SELECT * FROM hash_page_stats(get_raw_page('mytab_index', 1), 1)
As far as I can tell, that argument is only used to stuff into the output
field "blkno", it is not used to instruct the interpretation of the raw
page i
Hi,
I am getting a fatal error along with some warnings when trying to
apply the v3 patch using "git apply" command.
[ashu@localhost postgresql]$ git apply
0001-pageinspect-Hash-index-support_v3.patch
0001-pageinspect-Hash-index-support_v3.patch:29: trailing whitespace.
brinfuncs.o ginf
Ashutosh Bapat wrote:
> You may want to add this to the November commitfest
> https://commitfest.postgresql.org/11/.
Done. It's at https://commitfest.postgresql.org/11/799/
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
--
On 20/09/16 17:47, Robert Haas wrote:
> On Tue, Sep 20, 2016 at 11:27 AM, Peter Eisentraut
> wrote:
>> On 9/19/16 2:18 PM, Robert Haas wrote:
>>> I suggest that we make it part of bgw_flags, but use a bitmask for it,
>>> like this:
>>>
>>> #define BGWORKER_CLASS_MASK 0x00f0
>>> #define BGWORKER_
On Tue, Sep 20, 2016 at 1:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 26, 2016 at 7:44 PM, Michael Paquier
>> wrote:
>>> Yeah, it is definitely better to register it. And I have switched the
>>> patch as ready for committer just now.
>
>> Committed and back-patched to 9.4, where
On Tue, Sep 20, 2016 at 12:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, random() is the wrong thing. It should use PostmasterRandom().
>> Fixed to do that instead.
>
> I am not very happy about this patch; have you considered the security
> implications of what you just did?
Hmm. No.
Robert Haas writes:
> On Thu, May 26, 2016 at 7:44 PM, Michael Paquier
> wrote:
>> Yeah, it is definitely better to register it. And I have switched the
>> patch as ready for committer just now.
> Committed and back-patched to 9.4, where DSM was introduced.
ISTM both the previous coding and thi
Rudolf Gavlas wrote:
> I work in an environment, where servers are administered by people
> with different user names and identical uid (0).
So everyone is superuser there? That sounds, um, unorthodox.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila
wrote:
>
> Okay, Thanks for pointing out the same. I have fixed it. Apart from
> that, I have changed _hash_alloc_buckets() to initialize the page
> instead of making it completely Zero because of problems discussed in
> another related thread [1].
On Tue, Sep 20, 2016 at 8:34 PM, Tom Lane wrote:
> Pavan Deolasee writes:
> > I happened to notice this comment in src/include/storage/itemptr.h
>
> > * Note: because there is an item pointer in each tuple header and index
> > * tuple header on disk, it's very important not to waste space with
Robert Haas writes:
> Yeah, random() is the wrong thing. It should use PostmasterRandom().
> Fixed to do that instead.
I am not very happy about this patch; have you considered the security
implications of what you just did? If you haven't, I'll tell you:
you just made the postmaster's selectio
On Tue, Sep 20, 2016 at 5:40 AM, Jesper Pedersen wrote:
> On 09/20/2016 03:19 AM, Michael Paquier wrote:
>
>> You did not get right the comments from Alvaro upthread. The following
>> functions are added with this patch:
>> function hash_metap(text)
>> function hash_metap_bytea(bytea)
>> funct
Rudolf Gavlas writes:
> The usage of HOME environment variable (if set) is IMO the right,
> standard and faster way to get_home_path().
Can you provide some evidence for that claim? I can believe "faster"
but the rest sounds like wishful thinking.
> I work in an environment, where servers are a
On Thu, Oct 15, 2015 at 11:32 PM, Amit Kapila wrote:
> On Thu, Oct 15, 2015 at 8:35 PM, Dmitry Vasilyev
> wrote:
>>
>> I think that function dsm_impl_windows() with EACCES error should not
>> do ereport() with FATAL level. It works, but it is likely to make an
>> infinite loop if the user will re
On Thu, May 26, 2016 at 7:44 PM, Michael Paquier
wrote:
>> Thanks for reviewing the patch. I have added the entry for this patch in
>> next CF (https://commitfest.postgresql.org/10/636/), feel free to mark it
>> as Ready for committer if you think patch is good.
>
> Yeah, it is definitely better
Hi,
I work in an environment, where servers are administered by people
with different user names and identical uid (0). The attached patch
fixes a bug exposed in such environments: where the logic of
retrieving a personal configuration file relies solely on
get_home_path(), the different users are
On Tue, Sep 20, 2016 at 11:27 AM, Peter Eisentraut
wrote:
> On 9/19/16 2:18 PM, Robert Haas wrote:
>> I suggest that we make it part of bgw_flags, but use a bitmask for it,
>> like this:
>>
>> #define BGWORKER_CLASS_MASK 0x00f0
>> #define BGWORKER_CLASS_PARALLEL 0x0010
>> /* add additional bgwo
On Fri, Jul 1, 2016 at 3:10 AM, Etsuro Fujita
wrote:
> On 2016/04/14 4:57, Robert Haas wrote:
>>
>> 1. For a regular FDW scan, zero the xmin, xmax, and cid of the tuple
>> before returning it from postgres_fdw, so that we don't expose the
>> datum-tuple fields. I can't see any reason this isn't
On Mon, Jul 11, 2016 at 12:04 AM, Michael Paquier
wrote:
> On Sat, Jul 9, 2016 at 2:58 AM, Shoaib Lari wrote:
>> Besides making the error message more informative, we had to modify
>> allocate_recordbuf() to return the actual number of bytes that were being
>> allocated.
>
> - report_invali
On 9/18/16 4:17 PM, Steve Singer wrote:
> When I create my subscriber database by doing a physical backup of the
> publisher cluster (with cp before I add any data) then I am unable to
> connect subscribe.
> ie
> initdb ../data
> cp -r ../data ../data2
> ./postgres -D ../data
> ./postgres -D ../d
On 9/19/16 2:18 PM, Robert Haas wrote:
> I suggest that we make it part of bgw_flags, but use a bitmask for it,
> like this:
>
> #define BGWORKER_CLASS_MASK 0x00f0
> #define BGWORKER_CLASS_PARALLEL 0x0010
> /* add additional bgworker classes here */
Unless we have a mechanism that makes use of
On Tue, Sep 20, 2016 at 8:52 AM, Amit Kapila wrote:
> I think you have a point, but not sure if it is worth to add a
> separate file. It might be tricky to choose which file to add new
> tests for hash_indexes. Anybody else have opinion on this point?
I think all the tests should be added to has
On Thu, Sep 15, 2016 at 11:11:41AM +0530, Amit Kapila wrote:
> I think it is possible without breaking pg_upgrade, if we match all
> items of a page at once (and save them as local copy), rather than
> matching item-by-item as we do now. We are already doing similar for
> btree, refer explanation
On 9/19/16 1:22 PM, Robert Haas wrote:
> On Fri, Sep 16, 2016 at 4:28 PM, Alvaro Herrera
> wrote:
>> I agree it should be added. I suggest that it could even be added to
>> the 9.6 docs, if you can make it.
>
> Here's a patch. I intend to commit this pretty quickly unless
> somebody objects, an
Pavan Deolasee writes:
> I happened to notice this comment in src/include/storage/itemptr.h
> * Note: because there is an item pointer in each tuple header and index
> * tuple header on disk, it's very important not to waste space with
> * structure padding bytes. The struct is designed to be
On Tue, Sep 20, 2016 at 10:58 AM, Tom Lane wrote:
> Maybe it would be better to fix the rule against workers
> invoking their own parallel queries.
That rule does have the advantage of preventing us from having one
user backend launch N^2 workers. I don't think it would be that much
work to fix
On Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila wrote:
> I think here point is that for any case where there is count of rows
> to be selected, we disable parallelism. There are many genuine cases
> like select count(*) into cnt ... which will run to completion, but as
> plpgsql passes row count to
On Tue, Sep 20, 2016 at 2:20 AM, Tsunakawa, Takayuki
wrote:
> There's no apparent evidence to indicate the cause, but I could guess a few
> reasons. What do you think these are correct and should fix PostgreSQL? (I
> think so)
I think that we shouldn't start changing things based on guesses ab
Amit Kapila writes:
> On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas wrote:
>> However, I think the chances of supporting parallel query for queries
>> not executed to completion any time in the near future are very poor.
> I think here point is that for any case where there is count of rows
> to
On Mon, Sep 19, 2016 at 9:54 PM, Craig Ringer wrote:
>> You appear to have attached the wrong patch set.
>
> Whoops, multitasking fail.
>
> Sorry for the late response, hospitals are "fun".
I did some cleanup of 0001 (see attached) and was all set to commit it
when I realized what I think is a pr
>
> On 20 Sep 2016, at 09:40, Michael Paquier wrote:
>
Thanks for digging into this.
> + StartupCLOG();
> + StartupSUBTRANS(checkPoint.oldestActiveXid);
> + RecoverPreparedFromFiles();
> [...]
>/*
> -* Startup commit log and subtrans only. MultiXact and commit
>
On Thu, Sep 15, 2016 at 4:53 AM, Amit Langote
wrote:
> [ new patches ]
Re-reviewing 0001.
+ partexprs
+ pg_node_tree
This documentation doesn't match pg_partition_table.h, which has
partexprsrc and partexprbin. I don't understand why it's a good idea
to have both, and there seem to b
On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas wrote:
> On Sat, Sep 17, 2016 at 11:54 PM, Amit Kapila wrote:
>> In general, I think we should support the cases as required (or
>> written) by you from plpgsql or sql functions. We need more work to
>> support such cases. There are probably two ways
On Mon, Sep 19, 2016 at 8:44 PM, Mithun Cy wrote:
> On Sat, Aug 6, 2016 at 9:41 AM, Amit Kapila wrote:
>> I wonder why you have included a new file for these tests, why can't be
>> these added to existing hash_index.sql.
> tests in hash_index.sql did not cover overflow pages, above tests were for
On 09/20/2016 03:19 AM, Michael Paquier wrote:
You did not get right the comments from Alvaro upthread. The following
functions are added with this patch:
function hash_metap(text)
function hash_metap_bytea(bytea)
function hash_page_items(text,integer)
function hash_page_items_bytea(bytea)
f
Hi,
On 16/09/2016 05:11, Thomas Munro wrote:
Still no change measurable on my laptop. Keith, would you be able to
test this on your rig and see if it sucks any less than the last one?
I've tested kqueue-v6.patch on the Celeron NetBSD machine and numbers
were constantly lower by about 5-10% v
On 18.09.2016 06:54, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov wrote:
On 16.09.2016 16:50, Amit Kapila wrote:
Can you try by setting force_parallel_mode = off;? I think it is
sending the whole function execution to worker due to
force_parallel_mode.
No changes:
Hi Ashutosh,
Thank you for your answer. At the end I realized that the PGDLLEXPORT
keyword was missing from the functions definitions.
As a side question, what are the options to debug the plugin while it's
being executing? I've seen a debug plugin for Postgres but it seems more for
SQL functions
On Tue, Sep 20, 2016 at 10:51 AM, Amit Kapila wrote:
> On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova
> wrote:
>> 28.08.2016 09:13, Amit Kapila:
>>
>> On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova
>> wrote:
>>
>>
>> So the patch is correct.
>> We can go further and remove this i
On 03/17/2016 01:43 AM, Peter Geoghegan wrote:
I attach a revision, that makes all the changes that Heikki suggested,
except one. As already noted several times, following this suggestion
would have added a bug. Alvaro preferred my original approach here in
any case. I refer to my original approa
On Mon, Sep 19, 2016 at 6:11 PM, Pavel Stehule wrote:
> I am thinking so commit's description should be inside README
Horiguchi-san, your patch has some whitespace issues, you may want to
get a run with git diff --check. Here are some things I have spotted:
src/bin/psql/tab-complete.c:1074: trail
Hi,
I happened to notice this comment in src/include/storage/itemptr.h
* Note: because there is an item pointer in each tuple header and index
* tuple header on disk, it's very important not to waste space with
* structure padding bytes. The struct is designed to be six bytes long
* (it cont
On Tue, Sep 20, 2016 at 1:11 AM, Jesper Pedersen
wrote:
> This version adds the overloaded get_raw_page based methods. However, I'm
> not verifying the page other than page_id, as hasho_flag can contain
> multiple flags in Amit's patches. And, I don't see having different page ids
> as a benefit -
88 matches
Mail list logo
