Re: [HACKERS] Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename

On 15 December 2015 at 04:40, Craig Ringer wrote: > It gets written as part of the Form_pg_sequence each time we write a > sequence advance to WAL, but just seems to be a waste of space. > Agreed > Am I missing something obvious or should it just be removed? Or perhaps > replaced with the seq

Re: [HACKERS] pgbench stats per script & other stuff

On Tue, Dec 15, 2015 at 5:53 AM, Fabien COELHO wrote: > I wrote: >> Why would the likelyhood of an issue be small here? > > The time to update one stat (<< 100 cycles ?) to the time to do a > transaction with the database (typically Y ms), so the likelyhood of two > thread to update the very same

Re: [HACKERS] Remove array_nulls?

On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby wrote: > On 12/11/15 2:57 PM, Tom Lane wrote: >> Jim Nasby writes: >> Perhaps, but I'd like to have a less ad-hoc process about it. What's >> our policy for dropping backwards-compatibility GUCs? Are there any >> others that should be removed now as we

Re: [HACKERS] find_inheritance_children() and ALTER TABLE NO INHERIT

On 2015/12/03 15:30, Amit Langote wrote: > On 2015/12/03 13:09, Tom Lane wrote: >> Amit Langote writes: >>> Currently find_inheritance_children() is smart enough to skip a child >>> table that it finds has been dropped concurrently after it gets a lock on >>> the same. It does so by looking up the

Re: [HACKERS] Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename

On Tue, Dec 15, 2015 at 2:05 PM, Tom Lane wrote: > Craig Ringer writes: >> Does anyone know why Form_pg_sequence has a field sequence_name that >> duplicates the sequence's name from pg_class ? > > It's historical, for sure. We won't be removing it in the foreseeable > future because of on-disk-

[HACKERS] small query, about skipping dump in dumpAttrDef

Hi All, In dumpAttrDef() function we are skipping dump if table definition is not dumped(i.e. by checking tbinfo->dobj.dump), its absolutely alright to do this. But, in dumpConstraint() we doing same by checking constraint dump flag(coninfo->dobj.dump) instead of table dump flag(tbinfo->dobj.d

Re: [HACKERS] Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename

Craig Ringer writes: > Does anyone know why Form_pg_sequence has a field sequence_name that > duplicates the sequence's name from pg_class ? It's historical, for sure. We won't be removing it in the foreseeable future because of on-disk-compatibility issues. But you might want to read the pghac

[HACKERS] Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename

Hi all Does anyone know why Form_pg_sequence has a field sequence_name that duplicates the sequence's name from pg_class ? It's assigned when the sequence is created by copying it from pg_class. It isn't subsequently referenced anywhere as far as I can see. It isn't updated by ALTER SEQUENCE ...

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Wed, Dec 9, 2015 at 2:15 PM, Peter Geoghegan wrote: > I think that you're missing that patch 0001 formally forbids > abbreviated keys that are pass-by-value, by revising the contract > (this is proposed for backpatch to 9.5 -- only comments are changed). > This is already something that is all

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 14 December 2015 at 16:19, Craig Ringer wrote: > Attached a slightly updated version. It just has less spam in the > regression tests, by adding a new option to test_decoding to show > sequences, which it doesn't enable except in sequence specific tests. > Whoops, the patch as written is wro

Re: [HACKERS] Using quicksort for every external sort run

On Mon, Dec 14, 2015 at 7:22 PM, Peter Geoghegan wrote: > Thanks for taking the time to benchmark the patch! Also, I should point out that you didn't add work_mem past the point where the master branch will get slower, while the patch continues to get faster. This seems to happen fairly reliably,

Re: [HACKERS] Using quicksort for every external sort run

On Mon, Dec 14, 2015 at 6:58 PM, Greg Stark wrote: > I ran sorts with various parameters on my small NAS server. ... > without the extra memory optimizations. Thanks for taking the time to benchmark the patch! While I think it's perfectly fair that you didn't apply the final on-the-fly merge "

Re: [HACKERS] Tsvector editing functions

Hi, On 12/07/2015 03:05 PM, Stas Kelvich wrote: Hello. Done with the list of suggestions. Also heavily edit delete function. I did a quick review of the updated patch. I'm not a tsvector-expert so hopefully my comments won't be entirely bogus. 1) It's a bit difficult to judge the usefulne

Re: [HACKERS] Using quicksort for every external sort run

I ran sorts with various parameters on my small NAS server. This is a fairly slow CPU and limited memory machine with lots of disk so I thought it would actually make a good test case for smaller servers. The following is the speedup (for values < 100%) or slowdown (values > 100%) for the first pat

Re: [HACKERS] Patch: Optimize memory allocation in function 'bringetbitmap'

Hi, On 10/16/2015 08:00 PM, Jinyu Zhang wrote: Update the patch_brin_optimze_mem according to your comment. I've reviewed the last version of the patch, and I do have a few comments. I haven't done any performance testing at this point, as the machine I'm using for that is chewing on someth

Re: [HACKERS] Function and view to retrieve WAL receiver status

On Tue, Dec 15, 2015 at 5:27 AM, Gurjeet Singh wrote: > The function, maybe. But emitting an all-nulls row from a view seems > counter-intuitive, at least when looking at it in context of relational > database. OK, noted. Any other opinions? -- Michael -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

Hi, I was planning to do some review/testing on this patch, but then I noticed it was rejected with feedback in 2015-07 and never resubmitted into another CF. So I won't waste time in testing this unless someone shouts that I should do that anyway. Instead I'll just post some ideas about how

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > here is patch - supported syntax: \crosstabview VCol [+/-]HCol [HOrderCol] > > Order column should to contains any numeric value. Values are sorted on > client side If I understand correctly, I see a problem with HOrderCol. If the vertical header consists of, for

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > postgres=# \crosstabview 4 +month label > > Maybe using optional int order column instead label is better - then you can > do sort on client side > > so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol] In the meantime I've followed a different idea:

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Mon, Dec 14, 2015 at 2:50 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Quick followup: rl_resize_terminal() exists in GNU readline at least as >>> far back as 4.0 (released Feb 1999). However, it doesn't seem to be there >>> at all in libedit; I don't see it in OS X Yos

Re: [HACKERS] Parallel Aggregate

On Thu, Dec 10, 2015 at 10:42 PM, Haribabu Kommi wrote: > > Here I attached a POC patch of parallel aggregate based on combine > aggregate patch. This patch contains the combine aggregate changes > also. This patch generates and executes the parallel aggregate plan > as discussed in earlier thread

Re: [HACKERS] pgbench stats per script & other stuff

-Do not update pgbench_tellers and -pgbench_branches. -This will avoid update contention on these tables, but -it makes the test case even less like TPC-B. +Shorthand for -b simple-update@1. I don't think it is a good idea to remove entirely the descrip

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Alvaro Herrera writes: > Tom Lane wrote: >> Quick followup: rl_resize_terminal() exists in GNU readline at least as >> far back as 4.0 (released Feb 1999). However, it doesn't seem to be there >> at all in libedit; I don't see it in OS X Yosemite's headers, anyway. >> So we'd need a configure tes

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Tom Lane wrote: > I wrote: > > Merlin Moncure writes: > >> The following patch deals with a long standing gripe of mine that the > >> terminal frequently gets garbled so that when typing. > > > Hm. I wonder whether rl_resize_terminal() exists in every iteration > > of libreadline and libedit. >

Re: [HACKERS] Function and view to retrieve WAL receiver status

On Sun, Dec 13, 2015 at 10:15 PM, Michael Paquier wrote: > On Mon, Dec 14, 2015 at 3:09 PM, Gurjeet Singh > wrote: > > On Dec 13, 2015 9:56 PM, "Michael Paquier" > > wrote: > >> If the node has no WAL receiver active, a tuple with NULL values is > >> returned instead. > > > > IMO, in the absenc

[HACKERS] PATCH: postpone building buckets to the end of Hash (in HashJoin)

Hi, attached is v1 of one of the hashjoin improvements mentioned in September in the lengthy thread [1]. The main objection against simply removing the MaxAllocSize check (and switching to MemoryContextAllocHuge) is that if the number of rows is overestimated, we may consume significantly mo

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Merlin Moncure wrote: > On Tue, Dec 8, 2015 at 2:33 PM, Merlin Moncure wrote: > > On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote: > >> I wrote: > >>> Merlin Moncure writes: > The following patch deals with a long standing gripe of mine that the > terminal frequently gets garbled so tha

Re: [HACKERS] Uninterruptible slow geo_ops.c

Alvaro Herrera wrote: > While I'm not familiar with the code itself, and can't post the exact > slow query just yet, I have noticed that it is missing a > CHECK_FOR_INTERRUPTS() call to enable cancelling the slow query. I'd > backpatch this all the way back. (The exact issue they hit is mutual >

Re: [HACKERS] Proposal: custom compression methods

On 2015-12-14 14:50:57 +0800, Craig Ringer wrote: > http://www.postgresql.org/message-id/flat/20130615102028.gk19...@alap2.anarazel.de#20130615102028.gk19...@alap2.anarazel.de > The issue with per-Datum is that TOAST claims two bits of a varlena header, > which already limits us to 1 GiB varlena v

Re: [HACKERS] Proposal: custom compression methods

On 12/14/15 12:50 AM, Craig Ringer wrote: The issue with per-Datum is that TOAST claims two bits of a varlena header, which already limits us to 1 GiB varlena values, something people are starting to find to be a problem. There's no wiggle room to steal more bits. If you want pluggable compressio

Re: [HACKERS] parallel joins, and better parallel explain

On Wed, Dec 2, 2015 at 1:55 PM, Robert Haas wrote: > Oops. The new version I've attached should fix this. I've been trying to see if parallel join has any effect on PostGIS spatial join queries, which are commonly CPU bound. (My tests [1] on simple parallel scan were very positive, though quite

Re: [HACKERS] Another XML build issue

On Mon, Dec 14, 2015 at 10:56 AM, Kevin Grittner wrote: > On Mon, Dec 14, 2015 at 10:43 AM, Tom Lane wrote: > >> As I said, my inclination is to remove the SELECT xmlparse(document '') >> test case altogether. The following test SELECT xmlparse(document ' ') >> seems like it provides as much u

Re: [HACKERS] Remove array_nulls?

On 12/11/15 2:57 PM, Tom Lane wrote: Jim Nasby writes: A quick doc search indicates this config was created in 9.0, though the docs state it's for a change that happened in 8.2[1]. Don't know what you're looking at, but the GUC is definitely there (and documented) in 8.2. Is it time to remo

Re: [HACKERS] Logical replication and multimaster

I have updated DTM page at PoastgreSQL WiKi adding information about multimaster. Also we have created repository at github with our version of PostgreSQL and DTM extensions: multimaster, pg_dtm, pg_tsdtm,

Re: [HACKERS] Disabling an index temporarily

On Sun, Dec 13, 2015 at 10:23 PM, Bill Moran wrote: > On Sun, 13 Dec 2015 22:15:31 -0500 > Corey Huinker wrote: > > > ALTER TABLE foo DISABLE [NONUNIQUE] INDEXES > > -- same, but joining to pg_class and possibly filtering on indisunique > > I would think that NONUNIQUE should be the default, and

Re: [HACKERS] Disabling an index temporarily

On Sun, Dec 13, 2015 at 11:03 PM, Tom Lane wrote: > Jeff Janes writes: > > Not to hijack the thread even further in the wrong direction, but I > > think what Corey really wants here is to stop maintaining the index at > > retail while preserving the existing definition and existing index > > dat

Re: [HACKERS] Another XML build issue

On Mon, Dec 14, 2015 at 10:43 AM, Tom Lane wrote: > As I said, my inclination is to remove the SELECT xmlparse(document '') > test case altogether. The following test SELECT xmlparse(document ' ') > seems like it provides as much useful coverage as we need for that, > and its output doesn't de

Re: [HACKERS] Another XML build issue

Kevin Grittner writes: > On Mon, Dec 14, 2015 at 10:06 AM, Tom Lane wrote: >> So at this point I'm guessing that Ubuntu has shipped an update that >> includes the patch Pavel Raiskup suggested in >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1286692#c4 >> >> which would fix the lack of erro

Re: [HACKERS] Fdw cleanup

Hi, Albe, Thank you. The resource is not memory, I have something like a file descriptor or network connection, which I believe is the common case for foreign table. Using RegisterXactCallback exposes an API at a much deep level to foreign table writer, and I need to find a place to anchor the co

Re: [HACKERS] Another XML build issue

On Mon, Dec 14, 2015 at 10:06 AM, Tom Lane wrote: > So at this point I'm guessing that Ubuntu has shipped an update that > includes the patch Pavel Raiskup suggested in > > https://bugzilla.redhat.com/show_bug.cgi?id=1286692#c4 > > which would fix the lack of error cursors at EOF, but it would no

Re: [HACKERS] Another XML build issue

Kevin Grittner writes: > Today, on my ubuntu 14.04 LTS system, I saw an XML change come through > with updates. My build on master is now broken with this: > - line 1: Start tag expected, '<' not found > - > - ^ Now that I look more closely, there are really two distinct pathologies exhibited i

Re: [HACKERS] Fixing warnings in back branches?

On Mon, Dec 14, 2015 at 10:06 AM, Andres Freund wrote: > On 2015-12-14 09:43:07 -0500, Tom Lane wrote: >> Andres Freund writes: >> > On 2015-12-14 10:55:05 +, Greg Stark wrote: >> >> Perhaps just adding some -Wno-* flags would make more sense than >> >> changing code and possibly introducing

Re: [HACKERS] Another XML build issue

On Mon, Dec 14, 2015 at 9:44 AM, Tom Lane wrote: > Can you look to see if Ubuntu is carrying some > distro-specific patch that affects this? Here's what is in the log for the change that I think is the one that came through today: li

Re: [HACKERS] Another XML build issue

Kevin Grittner writes: > Today, on my ubuntu 14.04 LTS system, I saw an XML change come through > with updates. My build on master is now broken with this: > *** /home/kgrittn/pg/master/src/test/regress/expected/xml.out > 2015-11-23 08:15:28.206336200 -0600 > --- /home/kgrittn/pg/master/src/test

[HACKERS] Another XML build issue

Today, on my ubuntu 14.04 LTS system, I saw an XML change come through with updates. My build on master is now broken with this: *** /home/kgrittn/pg/master/src/test/regress/expected/xml.out 2015-11-23 08:15:28.206336200 -0600 --- /home/kgrittn/pg/master/src/test/regress/results/xml.out 2015-12-1

[HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Don't error if the two clusters are already on the sa

On Fri, Dec 11, 2015 at 8:44 PM, Michael Paquier wrote: > On Sat, Dec 12, 2015 at 9:11 AM, Tom Lane wrote: >> Peter Eisentraut writes: >>> pg_rewind: Don't error if the two clusters are already on the same timeline >>> This previously resulted in an error and a nonzero exit status, but >>> after

Re: [HACKERS] Fixing warnings in back branches?

On 2015-12-14 09:43:07 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2015-12-14 10:55:05 +, Greg Stark wrote: > >> Perhaps just adding some -Wno-* flags would make more sense than > >> changing code and possibly introducing bugs. > > > I think that's a case-by-case decision. Just verb

Re: [HACKERS] Fixing warnings in back branches?

Andres Freund writes: > On 2015-12-14 10:55:05 +, Greg Stark wrote: >> Perhaps just adding some -Wno-* flags would make more sense than >> changing code and possibly introducing bugs. > I think that's a case-by-case decision. Just verbatimly backpatching > something that stewed in master for

Re: [HACKERS] WIP: Rework access method interface

On 2015-12-12 23:17, Alexander Korotkov wrote: On Sat, Dec 12, 2015 at 9:21 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: On 2015-12-09 15:09, Alexander Korotkov wrote: ​Patch was rebased against current master. Any notes about current version of patch? It w

Re: [HACKERS] parallel joins, and better parallel explain

On Thu, Dec 3, 2015 at 3:25 AM, Robert Haas wrote: > > On Tue, Dec 1, 2015 at 7:21 AM, Amit Kapila wrote: > > It would be better if we can split this patch into multiple patches like > > Explain related changes, Append pushdown related changes, Join > > Push down related changes. You can choose

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 9:08 PM, Andres Freund wrote: > ALTER TABLE ALL IN TABLESPACE pg_default OWNED BY andres SET TABLESPACE > works, because of Missed that. - /* If we have TABLE SET TABLESPACE provide a list of tablespaces */ - else if (pg_strcasecmp(prev4_wd, "TABLE") == 0 &&

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Nov 9, 2015 at 6:46 AM, Robert Haas wrote: > On Sat, Nov 7, 2015 at 2:45 AM, Fabien COELHO wrote: >> After looking at the generated html version, I find that the "1/param" and >> "2/param" formula are very simple and pretty easy to read, and they would >> not be really enhanced with addit

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-14 20:58:21 +0900, Michael Paquier wrote: > On Mon, Dec 14, 2015 at 8:49 PM, Andres Freund wrote: > > On 2015-12-14 20:44:20 +0900, Michael Paquier wrote: > >> + /* > >> + * ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED > >> BY xxx > >> + * SET TABLESPAC

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 8:49 PM, Andres Freund wrote: > On 2015-12-14 20:44:20 +0900, Michael Paquier wrote: >> + /* >> + * ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED BY >> xxx >> + * SET TABLESPACE. >> + */ >> + else if (pg_strcasecmp(prev9_wd, "ALL")

Re: [HACKERS] Proposal: custom compression methods

On 13 December 2015 at 17:28, Alexander Korotkov wrote: > it would be nice to make compression methods pluggable. > Agreed. My thinking is that this should be combined with work to make use of the compressed data, which is why Alvaro, Tomas, David have been working on Col Store API for about 1

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

Hello, Robert Here is my fix for item 4. Best regards, Aleksander On Thu, 10 Dec 2015 11:37:23 -0500 Robert Haas wrote: > On Wed, Dec 9, 2015 at 8:30 AM, Aleksander Alekseev > wrote: > > Hello, Robert > > > > Thanks for your review. I believe I fixed items 1, 2 and 3 (see > > attachment). Als

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-14 20:44:20 +0900, Michael Paquier wrote: > + /* > + * ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED BY > xxx > + * SET TABLESPACE. > + */ > + else if (pg_strcasecmp(prev9_wd, "ALL") == 0 && > + pg_strcasecmp(prev8_wd, "IN")

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 8:36 PM, Andres Freund wrote: > On 2015-12-14 12:18:27 +0100, Andres Freund wrote: >> On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: >> > Hi all, >> > >> > I just bumped into the following thing while looking again at Thomas' >> > patch for psql tab completion: >> > -

Re: [HACKERS] Proposal: custom compression methods

On Mon, 14 Dec 2015 14:50:57 +0800 Craig Ringer wrote: > On 14 December 2015 at 01:28, Alexander Korotkov > wrote: > > > Hackers, > > > > I'd like to propose a new feature: "Custom compression methods". I missed the initial post on this thread ... Have you started or do you plan to actually s

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-14 12:18:27 +0100, Andres Freund wrote: > On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: > > Hi all, > > > > I just bumped into the following thing while looking again at Thomas' > > patch for psql tab completion: > > --- a/src/bin/psql/tab-complete.c > > +++ b/src/bin/psql/tab-co

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 8:18 PM, Andres Freund wrote: > On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: >> Hi all, >> >> I just bumped into the following thing while looking again at Thomas' >> patch for psql tab completion: >> --- a/src/bin/psql/tab-complete.c >> +++ b/src/bin/psql/tab-compl

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: > Hi all, > > I just bumped into the following thing while looking again at Thomas' > patch for psql tab completion: > --- a/src/bin/psql/tab-complete.c > +++ b/src/bin/psql/tab-complete.c > @@ -1040,7 +1040,7 @@ psql_completion(const char *text

Re: [HACKERS] Fixing warnings in back branches?

On 2015-12-14 10:55:05 +, Greg Stark wrote: > On Mon, Dec 14, 2015 at 10:20 AM, Andres Freund wrote: > > I personally am not bothered by a handful of spurious warnings in the > > back branches, but at this point you're very unlikely to see a new > > warning introduced into 9.1 while backpatchi

Re: [HACKERS] Fixing warnings in back branches?

On Mon, Dec 14, 2015 at 10:20 AM, Andres Freund wrote: > I personally am not bothered by a handful of spurious warnings in the > back branches, but at this point you're very unlikely to see a new > warning introduced into 9.1 while backpatching. These are new warnings older compilers didn't detec

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

David Fetter writes: > On Mon, Dec 14, 2015 at 03:06:18PM +0900, Michael Paquier wrote: >> On Sun, Dec 13, 2015 at 10:14 AM, Andreas Seltenreich wrote: >> > https://github.com/anse1/sqlsmith >> >> I am in awe regarding this stuff, which has caught many bugs >> already, it is a bit sad that it

[HACKERS] Fixing warnings in back branches?

Hi, While newer branches are at the moment mostly free of warnings for me, the picture is entirely different in the older back branches, especially 9.1. That has several hundred lines of warnings. I personally am not bothered by a handful of spurious warnings in the back branches, but at this poi

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

Thank you a lot! At Mon, 14 Dec 2015 17:51:41 +0900, Amit Langote wrote in <566e831d.1050...@lab.ntt.co.jp> > > Hi, > > On 2015/12/14 17:34, Kyotaro HORIGUCHI wrote: > > At Tue, 8 Dec 2015 10:40:20 -0500, Robert Haas wrote > >> But is it important enough to be worthwhile? Maybe, maybe not.

Re: [HACKERS] Support for N synchronous standby servers - take 2

Thank you for the new patch. At Wed, 9 Dec 2015 20:59:20 +0530, Masahiko Sawada wrote in > On Wed, Nov 18, 2015 at 2:06 PM, Masahiko Sawada > wrote: > > I agree with #3 way and the s_s_name format you suggested. > > I think that It's extensible and is tolerable for future changes. > > I'm goi

Re: [HACKERS] Uninterruptible slow geo_ops.c

On 11/12/15 19:18, Marco Nenciarini wrote: > On 11/12/15 18:48, Alvaro Herrera wrote: >> Hi, >> >> A customer of ours hit some very slow code while running the >> @>(polygon, polygon) operator with some big polygons. I'm not familiar >> with this stuff but I think the problem is that the algorithm

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

Hi, On 2015/12/14 17:34, Kyotaro HORIGUCHI wrote: > At Tue, 8 Dec 2015 10:40:20 -0500, Robert Haas wrote >> But is it important enough to be worthwhile? Maybe, maybe not. I >> think we should be working toward a world where the Gather is at the >> top of the plan tree as often as possible, in

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

Hello, thank you for the comment. At Tue, 8 Dec 2015 10:40:20 -0500, Robert Haas wrote in > On Mon, Nov 30, 2015 at 7:47 AM, Kyotaro HORIGUCHI > wrote: > > "Asynchronous execution" is a feature to start substantial work > > of nodes before doing Exec*. This can reduce total startup time > > by

Re: [HACKERS] W-TinyLfu for cache eviction

On Mon, Dec 14, 2015 at 12:18 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > a global lock would be good enough for a proof of concept that only > evaluates cache hit ratios. > > I think emulator can be used to check hit ratios. That way we can see > how different algorithms affect

Re: [HACKERS] Fdw cleanup

Feng Tian wrote: > I need some help to understand foreign table error handling. > > For a query on foreign table, ExecInitForeignScan is called, which in turn > calls the BeginForeignScan > hook. Inside this hook, I allocated some resource, > > > node->fdw_state = allocate_resource(...); > >

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 14 December 2015 at 11:28, Craig Ringer wrote: > Hi all > > Attached is a patch against 9.6 to add support for informing logical > decoding plugins of the new sequence last_value when sequence advance WAL > records are processed during decoding. > Attached a slightly updated version. It just