Re: [HACKERS] GSoC 2017

Count me in as a mentor On 10-Jan-2017 3:24 PM, "Alexander Korotkov" wrote: > Hi all! > > In 2016 PostgreSQL project didn't pass to GSoC program. In my > understanding the reasons for that are following. > > 1. We did last-minute submission of our application to

Re: [HACKERS] PROPOSAL: Fast temporary tables

On Tue, Mar 1, 2016 at 9:30 PM, Robert Haas wrote: > On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane wrote: > > Aleksander Alekseev writes: > >> There are applications that create and delete a lot of temporary > >> tables.

Re: [HACKERS] PROPOSAL: Fast temporary tables

> > > > I think you have no concept how invasive that would be. Tables not > represented in the catalogs would be a disaster, because *every single > part of the backend* would have to be modified to deal with them as > a distinct code path --- parser, planner, executor, loads and loads > of

Re: [HACKERS] PROPOSAL: Fast temporary tables

On Tue, Mar 1, 2016 at 8:55 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > Hello > > There are applications that create and delete a lot of temporary > tables. Currently PostgreSQL doesn't handle such a use case well. > Consider the following benchmark/example. > > FWIW, I and

Re: [HACKERS] about google summer of code 2016

On 19 Feb 2016 8:30 am, "Chapman Flack" wrote: > > On 02/18/16 19:35, Amit Langote wrote: > > > Apparently, the deadline is: February 20, 2016 at 04:00 (+0900 UTC) > > > > https://summerofcode.withgoogle.com/ > > For anybody finding that web site as anti-navigable as I did,

Re: [HACKERS] 2016-01 Commitfest

On Mon, Jan 18, 2016 at 11:05 PM, Alvaro Herrera wrote: > Two weeks into the commitfest, things have moved a bit: > > Needs review: 53. > Waiting on Author: 20. > Ready for Committer: 10. > Committed: 16. > Total: 99.

Re: [HACKERS] Accessing non catalog table in backend

On Tue, Jan 5, 2016 at 11:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Atri Sharma <atri.j...@gmail.com> writes: > > I fail to see the relevance of which node is getting evaluated (its a > Plan > > node BTW) for this question. The concern I had was around using SPI

Re: [HACKERS] Accessing non catalog table in backend

On Mon, Jan 11, 2016 at 10:48 PM, Atri Sharma <atri.j...@gmail.com> wrote: > Sorry, I missed this email. > > I was specifically targeting accessing tables inside Node evaluation hence > do not want to add new nodes. > > Thanks for your inputs! > > Regards, > >

Re: [HACKERS] Accessing non catalog table in backend

Sorry, I missed this email. I was specifically targeting accessing tables inside Node evaluation hence do not want to add new nodes. Thanks for your inputs! Regards, Atri On Tue, Jan 5, 2016 at 11:43 AM, Amit Langote <langote_amit...@lab.ntt.co.jp > wrote: > On 2016/01/05 14:30, At

Re: [HACKERS] Accessing non catalog table in backend

Thanks! I was wary to use SPI inside the executor for node evaluation functions. Does it seem safe? Regards, Atri On 5 Jan 2016 12:20 am, "Jim Nasby" <jim.na...@bluetreble.com> wrote: > On 1/4/16 12:07 PM, Atri Sharma wrote: > >> Hi All, >> >> I wanted t

Re: [HACKERS] Accessing non catalog table in backend

On Tue, Jan 5, 2016 at 9:54 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2016/01/05 3:53, Atri Sharma wrote: > > I was wary to use SPI inside the executor for node evaluation functions. > > Does it seem safe? > > What is "node evaluation functio

[HACKERS] Accessing non catalog table in backend

Hi All, I wanted to check if it is possible to query a non catalog table in backend. I understand that cql interface is only for catalog querying hence it is not usable for this purpose per se. Please advice. Regards, Atri

Re: [HACKERS] Threads in PostgreSQL

On Mon, Dec 21, 2015 at 11:51 AM, sri harsha wrote: > Hi, > >Is it possible to use threads in Postgresql ?? I am using threads in my > foreign data wrapper and i get the following error when i use the threads . > > *ERROR: stack depth limit exceeded* > *HINT:

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

> I think the general idea is that if Commit is WAL logged, then the > operation is considered to committed on local node and commit should > happen on any node, only once prepare from all nodes is successful. > And after that transaction is not supposed to abort. But I think you are > trying to

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

> I'm thinking the client should get some kind of a token back from the commit, and it could use the token on the standby, to wait for that commit to be applied. The token could be just the XID, or the LSN of the commit record. Or the application could generate the token and pass it to the server

Re: [HACKERS] count_nulls(VARIADIC any)

On Thu, Aug 13, 2015 at 12:55 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-08-13 9:21 GMT+02:00 Marko Tiikkaja ma...@joh.to: On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote: nnulls() I think I'd prefer num_nulls() over that. can be what about similar twin function

Re: [HACKERS] Commitfest remaining Needs Review items

* Unique Joins Still needs to be reviewed. Any volunteers? Can take this one up, if its within my limits.

Re: [HACKERS] Updatable view?

On 31 Jul 2015 11:59, Tatsuo Ishii is...@postgresql.org wrote: On 31 Jul 2015 10:15, Tatsuo Ishii is...@postgresql.org wrote: I think it would be nice to have... but not to the point of working on it myself. Might be worth an email to -general to see how many people have

Re: [HACKERS] Memory Accounting v11

On Wed, Jul 15, 2015 at 12:57 PM, Jeff Davis pg...@j-davis.com wrote: On Tue, 2015-07-14 at 16:19 -0400, Robert Haas wrote: tuplesort.c does its own accounting, and TBH that seems like the right thing to do here, too. The difficulty is, I think, that some transition functions use an

Re: [HACKERS] [idea] table partition + hash join

On Wed, Jun 10, 2015 at 2:16 PM, Amit Langote langote_amit...@lab.ntt.co.jp wrote: Perhaps the qual needs to be pushed all the way down to the Hash's underlying scan if that makes sense. And that is a Pandora's box of troubles IMHO unless done in a very careful manner.

Re: [HACKERS] Improving GEQO

On Fri, May 29, 2015 at 12:59 AM, Merlin Moncure mmonc...@gmail.com wrote: On Wed, May 27, 2015 at 3:06 PM, boix b...@uclv.cu wrote: Hello, my partner and me are working with the goal of improve the GEQO's performance, we tried with Ant Colony Optimization, but it does not improve,

Re: [HACKERS] Support UPDATE table SET(*)=...

Hi all, Sorry for the delay. Please find attached latest version of UPDATE (*) patch.The patch implements review comments and Tom's gripe about touching transformTargetList is addressed now. I have added regression tests and simplified parser representation a bit. Regards, Atri diff --git

Re: [HACKERS] [pgsql-advocacy] GSoC 2015 - mentors, students and admins.

I am up for mentoring again. On 10 Feb 2015 02:23, Thom Brown t...@linux.com wrote: Hi all, Google Summer of Code 2015 is approaching. I'm intending on registering PostgreSQL again this year. Before I do that, I'd like to have an idea of how many people are interested in being either a

Re: [HACKERS] Implementation of global temporary tables?

Some was changed from 2009: * We have updatable CTE * We have unlogged tables Opened questions: 1. Name and conformance with standard of this feature - because we doesn't support modules, a mapping ANSI - PG should not be trivial 2. Implementation I see three possible ways how to

Re: [HACKERS] Implementation of global temporary tables?

1. Main catalogue will be stable. 2. There is not necessary to implement new storage and it can helps with transaction support. The amount of complexity that'd be involved to store catalog data in a separate relation around the caches and accesses would be significant. I don't think

Re: [HACKERS] Implementation of global temporary tables?

On Mon, Feb 2, 2015 at 6:34 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-02-02 13:36 GMT+01:00 Atri Sharma atri.j...@gmail.com: 1. Main catalogue will be stable. 2. There is not necessary to implement new storage and it can helps with transaction support. The amount

[HACKERS] Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

On Tuesday, January 6, 2015, Amit Langote langote_amit...@lab.ntt.co.jp wrote: On 06-01-2015 PM 04:26, Atri Sharma wrote: On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote langote_amit...@lab.ntt.co.jp javascript:; wrote: Though, I have no strong opinion on whether one thing is good

Re: [HACKERS] Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

The overhead of this patch is small. A new path is added for the preorder keys, and OrderCheck node's additional cost is pretty low, given that it only compares two rows and stores only a single row (previous row seen), hence the memory footprint is minuscule. We can eliminate the new

Re: [HACKERS] Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote langote_amit...@lab.ntt.co.jp wrote: On 06-01-2015 PM 04:00, Ashutosh Bapat wrote: On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma atri.j...@gmail.com wrote: We can eliminate the new node and put onus or having the right order on the user like

Re: [HACKERS] Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

On Tue, Jan 6, 2015 at 12:30 PM, Ashutosh Bapat ashutosh.ba...@enterprisedb.com wrote: On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma atri.j...@gmail.com wrote: Even checking whether the output of the function is in the right order or not, has its cost. I am suggesting that we can

Re: [HACKERS] Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

On Mon, Jan 5, 2015 at 11:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: David G Johnston david.g.johns...@gmail.com writes: Atri Sharma wrote If order of result rows is not the same as required, an error is raised: SELECT * FROM incorrect_order_nulls() ORDER BY e NULLS LAST; ERROR: Order

[HACKERS] Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

Hi All, Please forgive if this is a repost. Please find attached patch for supporting ORDER BY clause in CREATE FUNCTION for SRFs. Specifically: CREATE OR REPLACE FUNCTION func1(OUT e int, OUT f int) returns setof record as ' SELECT a,b FROM table1 ORDER BY a; ' language 'sql' ORDER BY e; This

Re: [HACKERS] Final Patch for GROUPING SETS

ChainAggregate is a bit like a node having two parents, a Sort and a GroupAggregate. However, the graph edge between ChainAggregate and its GroupAggregate is a tuplestore instead of the usual, synchronous ExecProcNode(). Well, I dont buy the two parents theory. The Sort nodes are

Re: [HACKERS] mysql with postgres

On Tue, Dec 23, 2014 at 3:06 PM, Ravi Kiran ravi.kolanp...@gmail.com wrote: hi all, Is postgres source code compatible with mysql database?? If it is, could someone could give me some links so that I can do that. I want to hack into the postgres source code, but as I am comfortable with

Re: [HACKERS] Final Patch for GROUPING SETS

On Tuesday, December 23, 2014, Robert Haas robertmh...@gmail.com wrote: On Mon, Dec 22, 2014 at 11:19 AM, Andrew Gierth and...@tao11.riddles.org.uk javascript:; wrote: Tom The other reason that's a bad comparison is that I've not seen Tom many queries that use more than a couple of window

Re: [HACKERS] Commitfest problems

On Thu, Dec 18, 2014 at 8:44 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: On Wed, Dec 17, 2014 at 5:00 PM, Stephen Frost sfr...@snowman.net wrote: Another thought I had was to suggest we consider *everyone* to be a contributor and implement a way to tie together the

Re: [HACKERS] Combining Aggregates

On Wed, Dec 17, 2014 at 3:23 PM, Simon Riggs si...@2ndquadrant.com wrote: KaiGai, David Rowley and myself have all made mention of various ways we could optimize aggregates. Following WIP patch adds an extra function called a combining function, that is intended to allow the user to specify

Re: [HACKERS] Combining Aggregates

On Wed, Dec 17, 2014 at 6:05 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: Simon, Its concept is good to me. I think, the new combined function should be responsible to take a state data type as argument and update state object of the aggregate function. In other words, combined function

Re: [HACKERS] Combining Aggregates

On Wed, Dec 17, 2014 at 7:18 PM, Simon Riggs si...@2ndquadrant.com wrote: On 17 December 2014 at 12:35, Kouhei Kaigai kai...@ak.jp.nec.com wrote: Its concept is good to me. I think, the new combined function should be responsible to take a state data type as argument and update state object

Re: [HACKERS] Commitfest problems

On Wed, Dec 17, 2014 at 12:03 AM, Stephen Frost sfr...@snowman.net wrote: David, * David Rowley (dgrowle...@gmail.com) wrote: I'd just like to add something which might be flying below the radar of more senior people. There are people out there (ike me) working on PostgreSQL more for

Re: [HACKERS] Support UPDATE table SET(*)=...

On Mon, Dec 8, 2014 at 6:06 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane t...@sss.pgh.pa.us wrote: I think what's likely missing here is a clear design for the raw parse tree representation (what's returned by the bison grammar). The patch

Re: [HACKERS] Removing INNER JOINs

On Wed, Dec 3, 2014 at 5:00 PM, Simon Riggs si...@2ndquadrant.com wrote: On 3 December 2014 at 09:29, David Rowley dgrowle...@gmail.com wrote: *** Method 3: Marking scans as possibly skippable during planning and removing redundant join nodes at executor startup (Simon's method) Pros:

Re: [HACKERS] Removing INNER JOINs

On Wed, Dec 3, 2014 at 8:32 PM, Stephen Frost sfr...@snowman.net wrote: * Atri Sharma (atri.j...@gmail.com) wrote: So the planner keeps all possibility satisfying plans, or it looks at the possible conditions (like presence of foreign key for this case, for eg) and then lets executor

Re: [HACKERS] Removing INNER JOINs

On Wed, Dec 3, 2014 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote: Stephen Frost sfr...@snowman.net writes: * Tom Lane (t...@sss.pgh.pa.us) wrote: However, even granting that that is a concern, so what? You *have* to do the planning twice, or you're going to be generating a crap plan for

Re: [HACKERS] Removing INNER JOINs

On Wed, Dec 3, 2014 at 11:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: Atri Sharma atri.j...@gmail.com writes: Is it possible to only replan part of the plan in case of this optimization? I think that we might need to only replan parts of the original plan (as you mentioned, join search

Re: [HACKERS] Removing INNER JOINs

On Wed, Dec 3, 2014 at 11:27 PM, Stephen Frost sfr...@snowman.net wrote: * Atri Sharma (atri.j...@gmail.com) wrote: Agreed, but in some cases, we could possibly make some assumptions (if there is no index, if a large fraction of table will be returned in scan, FunctionScan). All neat

Re: [HACKERS] Removing INNER JOINs

On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Stephen Frost sfr...@snowman.net writes: * Atri Sharma (atri.j...@gmail.com) wrote: Agreed, but in some cases, we could possibly make some assumptions (if there is no index, if a large fraction of table will be returned

Re: [HACKERS] Removing INNER JOINs

On Wed, Dec 3, 2014 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Atri Sharma atri.j...@gmail.com writes: On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: I think the right approach for now is to emulate the GEQO precedent as closely as possible. Build all the single

Re: [HACKERS] using custom scan nodes to prototype parallel sequential scan

On Wed, Nov 12, 2014 at 1:24 PM, David Rowley dgrowle...@gmail.com wrote: On Tue, Nov 11, 2014 at 9:29 PM, Simon Riggs si...@2ndquadrant.com wrote: This plan type is widely used in reporting queries, so will hit the mainline of BI applications and many Mat View creations. This will allow

Re: [HACKERS] Representing a SRF return column in catalogs

On Fri, Nov 7, 2014 at 7:15 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Nov 5, 2014 at 8:24 AM, Atri Sharma atri.j...@gmail.com wrote: I am working on something that requires representing a SRF return column in pg_proc and being able to retrieve it, retrieve the name of the column

Re: [HACKERS] Representing a SRF return column in catalogs

On Saturday, November 8, 2014, Tom Lane t...@sss.pgh.pa.us wrote: I'm confused too. The original example seemed to imagine that details of a query (not the function, but the calling query) would be stored in the catalogs, which is completely nuts. pg_proc already has provisions to remember

[HACKERS] Representing a SRF return column in catalogs

Hi, I am working on something that requires representing a SRF return column in pg_proc and being able to retrieve it, retrieve the name of the column and make a ColumnRef node from it. The catch here are aliases: SELECT generate_series(1,100) AS a ORDER BY a; I need to know that the return

Re: [HACKERS] How to implent CONVERT ( data_type [ ( length ) ] , expression ) function in postgreSQL

On Sun, Nov 2, 2014 at 3:40 PM, rohtodeveloper rohtodevelo...@outlook.com wrote: Dear In SQLServer, there'are two functions to converte an expression of one data type to another. 1. CAST ( expression AS data_type [ ( length ) ] ) 2. CONVERT ( data_type [ ( length ) ] , expression )

Re: [HACKERS] proposal: CREATE DATABASE vs. (partial) CHECKPOINT

To solve #1, we could redesign CREATE DATABASE so that replaying the DBASE_CREATE record doesn't zap the old directory, and also doesn't copy any files. We could instead just assume that if the transaction commits, all the files have been copied and fsync'd already, like we assume that if

Re: [HACKERS] proposal: CREATE DATABASE vs. (partial) CHECKPOINT

On Mon, Oct 27, 2014 at 4:44 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 10/27/2014 01:06 PM, Atri Sharma wrote: To solve #1, we could redesign CREATE DATABASE so that replaying the DBASE_CREATE record doesn't zap the old directory, and also doesn't copy any files. We could

Re: [HACKERS] proposal: CREATE DATABASE vs. (partial) CHECKPOINT

IMHO writing all the data into a WAL would be the cleanest solution. Also, what is a small database? I don't think a static value will work, because the sweet spot between the current approach (forcing two checkpoints) and writing everything in WAL depends on the amount of dirty buffers

Re: [HACKERS] Support UPDATE table SET(*)=...

On Fri, Oct 17, 2014 at 7:45 PM, Merlin Moncure mmonc...@gmail.com wrote: On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma atri.j...@gmail.com wrote: On Wednesday, October 15, 2014, Marti Raudsepp ma...@juffo.org wrote: Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma atri.j

[HACKERS] Support UPDATE table SET(*)=...

Hi All, Please find attached a patch which implements support for UPDATE table1 SET(*)=... The patch supports both UPDATE table SET(*)=(a,b,c) and UPDATE table1 SET(*)=(SELECT a,b,c FROM...). It solves the problem of doing UPDATE from a record variable of the same type as the table e.g. update

Re: [HACKERS] Support UPDATE table SET(*)=...

On Wednesday, October 15, 2014, Marti Raudsepp ma...@juffo.org wrote: Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma atri.j...@gmail.com javascript:; wrote: Please find attached a patch which implements support for UPDATE table1 SET(*)=... I presume you haven't read Tom Lane's

Re: [HACKERS] Support UPDATE table SET(*)=...

On Wed, Oct 15, 2014 at 2:18 PM, Atri Sharma atri.j...@gmail.com wrote: On Wednesday, October 15, 2014, Marti Raudsepp ma...@juffo.org wrote: Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma atri.j...@gmail.com wrote: Please find attached a patch which implements support for UPDATE

Re: [HACKERS] Postgres code for a query intermediate dataset

On Sunday, September 14, 2014, Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote: On 14/09/14 05:36, Rohit Goyal wrote: Hi All, I want to work on the code of intermediate dataset of select and update query. For example. Rohit's salary has been updated 4 times, so it has 4 different

Re: [HACKERS] Postgres code for a query intermediate dataset

On Sun, Sep 14, 2014 at 1:30 PM, Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote: On 14/09/14 19:25, Atri Sharma wrote: On Sunday, September 14, 2014, Mark Kirkwood mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz wrote: On 14/09/14 05:36, Rohit Goyal wrote

Re: [HACKERS] Postgres code for a query intermediate dataset

On Sun, Sep 14, 2014 at 1:30 PM, Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote: On 14/09/14 19:25, Atri Sharma wrote: On Sunday, September 14, 2014, Mark Kirkwood mark.kirkw...@catalyst.net.nz mailto:mark.kirkw...@catalyst.net.nz wrote: On 14/09/14 05:36, Rohit Goyal wrote

Re: [HACKERS] Postgres code for a query intermediate dataset

On Sat, Sep 13, 2014 at 11:06 PM, Rohit Goyal rhtgyl...@gmail.com wrote: Hi All, I want to work on the code of intermediate dataset of select and update query. For example. Rohit's salary has been updated 4 times, so it has 4 different version of salary. I want to select salary of

Re: [HACKERS] Postgres code for a query intermediate dataset

On Sat, Sep 13, 2014 at 11:52 PM, David G Johnston david.g.johns...@gmail.com wrote: Atri Sharma wrote On Sat, Sep 13, 2014 at 11:06 PM, Rohit Goyal lt; Or rather even if you want to be able to reference the older versions of that record there is nothing in PostgreSQL to facilitate

Re: [HACKERS] Join push-down support for foreign tables

On Fri, Sep 5, 2014 at 2:20 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Sep 4, 2014 at 11:56 AM, Bruce Momjian br...@momjian.us wrote: I am thinking eventually we will need to cache the foreign server statistics on the local server. Wouldn't that lead to issues where the

Re: [HACKERS] Join push-down support for foreign tables

On Thursday, September 4, 2014, Bruce Momjian br...@momjian.us wrote: On Thu, Sep 4, 2014 at 08:37:08AM -0400, Robert Haas wrote: The main problem I see here is that accurate costing may require a round-trip to the remote server. If there is only one path that is probably OK; the cost of

Re: [HACKERS] Join push-down support for foreign tables

On Thu, Sep 4, 2014 at 9:26 PM, Bruce Momjian br...@momjian.us wrote: On Thu, Sep 4, 2014 at 08:41:43PM +0530, Atri Sharma wrote: On Thursday, September 4, 2014, Bruce Momjian br...@momjian.us wrote: On Thu, Sep 4, 2014 at 08:37:08AM -0400, Robert Haas wrote: The main

Re: [HACKERS] Join push-down support for foreign tables

On Thu, Sep 4, 2014 at 9:33 PM, Bruce Momjian br...@momjian.us wrote: On Thu, Sep 4, 2014 at 09:31:20PM +0530, Atri Sharma wrote: I am thinking we would eventually have to cache the statistics, then get some kind of invalidation message from the foreign server. I am also

Re: [HACKERS] Final Patch for GROUPING SETS - unrecognized node type: 347

On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers e...@xs4all.nl wrote: On Tue, August 26, 2014 14:24, Andrew Gierth wrote: Erik == Erik Rijkers e...@xs4all.nl writes: They apply cleanly for me at 2bde297 whether with git apply or patch, except for the contrib one (which you don't need

Re: [HACKERS] Final Patch for GROUPING SETS - unrecognized node type: 347

On Sunday, August 31, 2014, Andres Freund and...@2ndquadrant.com wrote: On 2014-08-31 21:09:59 +0530, Atri Sharma wrote: On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers e...@xs4all.nl javascript:; wrote: I have found that the unrecognized node type error is caused by: It's a warning

Re: [HACKERS] COPY and heap_sync

On Saturday, August 30, 2014, Amit Kapila amit.kapil...@gmail.com wrote: On Sat, Aug 30, 2014 at 11:56 AM, Jeff Janes jeff.ja...@gmail.com javascript:_e(%7B%7D,'cvml','jeff.ja...@gmail.com'); wrote: If you insert tuples with COPY into a table created or truncated in the same transaction,

Re: [HACKERS] 9.5: Memory-bounded HashAgg

On Thursday, August 14, 2014, Jeff Davis pg...@j-davis.com wrote: On Thu, 2014-08-14 at 10:06 -0400, Tom Lane wrote: If you're following the HashJoin model, then what you do is the same thing it does: you write the input tuple back out to the pending batch file for the hash partition that

Re: [HACKERS] 9.5: Memory-bounded HashAgg

On Thu, Aug 14, 2014 at 10:21 PM, Tomas Vondra t...@fuzzy.cz wrote: On 14 Srpen 2014, 18:02, Atri Sharma wrote: On Thursday, August 14, 2014, Jeff Davis pg...@j-davis.com wrote: On Thu, 2014-08-14 at 10:06 -0400, Tom Lane wrote: If you're following the HashJoin model, then what you do

Re: [HACKERS] Shared Data Structure b/w clients

On Tuesday, July 22, 2014, Rohit Goyal rhtgyl...@gmail.com wrote: Hi All, I am working on postgresql code and having some problem. :) I need to create shared data structure, so that different client and connection can update and share the state of those data structures in memory. I planned

Re: [HACKERS] how to skip building certain paths in path tree

On Tue, Jul 22, 2014 at 10:53 AM, Rajmohan C csrajmo...@gmail.com wrote: How do I modify PostgreSQL 9.3 source to skip certain join combinations (skip building certain paths in path tree) by checking some condition have a look at joinpaths.c

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On Tue, Jul 1, 2014 at 4:54 AM, Tomas Vondra t...@fuzzy.cz wrote: On 30.6.2014 23:12, Tomas Vondra wrote: Hi, attached is v5 of the patch. The main change is that scaling the number of buckets is done only once, after the initial hash table is build. The main advantage of this is lower

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On Thu, Jul 3, 2014 at 11:40 PM, Stephen Frost sfr...@snowman.net wrote: Tomas, * Tomas Vondra (t...@fuzzy.cz) wrote: However it's likely there are queries where this may not be the case, i.e. where rebuilding the hash table is not worth it. Let me know if you can construct such query (I

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

On Mon, Jun 16, 2014 at 11:28 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Mon, May 26, 2014 at 6:23 AM, Ronan Dunklau ronan.dunk...@dalibo.com wrote: Le dimanche 25 mai 2014 12:41:18 David Fetter a écrit : On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote: Hello,

Re: [HACKERS] Congrats Andres Freund, the newest PostgreSQL Commiter!

Congrats Andres! On Fri, May 23, 2014 at 7:54 AM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: Hi All, At the Developer Meeting that occurred 21th May 2014 was announced a new PostgreSQL commiter [1], Mr. Andres Freund. I had the opportunity to work and be mentored by him. He

Re: [HACKERS] is there a hook by which we can modify input query before postgresql builds raw parse tree

On Fri, May 2, 2014 at 10:07 AM, Rajmohan C csrajmo...@gmail.com wrote: Hi, I want to know is there a way to use a hook to modify the input query before Postgresql parses and builds the parse tree for the query. Uh...the rewriter? -- Regards, Atri *l'apprenant*

Re: [HACKERS] Hashable custom types

The plain UNION code supports either sorting or hashing, but we've not gotten around to supporting a sort-based approach to recursive UNION. I'm not convinced that it's worth doing ... regards, tom lane Without sorting, isnt the scope of a recursive UNION with

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Tue, Apr 22, 2014 at 12:59 PM, Albe Laurenz laurenz.a...@wien.gv.atwrote: Jason Petersen wrote: Yes, we obviously want a virtual clock. Focusing on the use of gettimeofday seems silly to me: it was something quick for the prototype. The problem with the clocksweeps is they don’t

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Sat, Apr 19, 2014 at 3:37 AM, Bruce Momjian br...@momjian.us wrote: One thing that I discussed with Merlin offline and am now concerned about is how will the actual eviction work. We cannot traverse the entire list and then find all the buffers with refcount 0 and then do another

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Fri, Apr 18, 2014 at 7:27 AM, Peter Geoghegan p...@heroku.com wrote: A way I have in mind about eviction policy is to introduce a way to have an ageing factor in each buffer and take the ageing factor into consideration when evicting a buffer. Consider a case where a table is pretty huge and

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Sat, Apr 19, 2014 at 1:07 AM, Bruce Momjian br...@momjian.us wrote: On Fri, Apr 18, 2014 at 04:46:31PM +0530, Atri Sharma wrote: This can be changed by introducing an ageing factor that sees how much time the current buffer has spend in shared buffers. If the time that the buffer has

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

Yes, we obviously want a virtual clock. Focusing on the use of gettimeofday seems silly to me: it was something quick for the prototype. The problem with the clocksweeps is they don’t actually track the progression of “time” within the PostgreSQL system. What’s wrong with using a transaction

Re: [HACKERS] Autonomous Transaction (WIP)

On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule pavel.steh...@gmail.comwrote: 2014-04-07 11:59 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com: On 07 April 2014 12:12, Pavel Stehule wrote: +1 for feature Thanks -1 for Oracle syntax - it is hardly inconsistent with Postgres We

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

On Thu, Mar 20, 2014 at 8:10 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Mar 18, 2014 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: Atri Sharma atri.j...@gmail.com writes: One of the factors that leads to bad estimates is that the histogram of the values of a column maintained

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

On Thu, Mar 20, 2014 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: Atri Sharma atri.j...@gmail.com writes: Now, why cannot we take the estimate of all the buckets behind the bucket in which our value is present? Will that estimate not give us the fraction of tuples that are expected

Re: [HACKERS] Optimized out tags

On Fri, Mar 21, 2014 at 9:49 AM, Rajashree Mandaogane rajashree@gmail.com wrote: What can be done to get rid of the 'optimized out' tags while debugging? Did you use the appropriate debugging flags when running ./configure? Regards, Atri -- Regards, Atri *l'apprenant*

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

On Tue, Mar 18, 2014 at 11:43 PM, Josh Berkus j...@agliodbs.com wrote: On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah. I would like to see the planner's cost estimates extended to include some sort of uncertainty estimate, whereupon risk-averse people could ask

Re: [HACKERS] Planner hints in Postgresql

That's precisely what risk estimation was about. Yeah. I would like to see the planner's cost estimates extended to include some sort of uncertainty estimate, whereupon risk-averse people could ask it to prefer low-uncertainty plans over high-uncertainty ones (the plans we typically

Re: [HACKERS] Planner hints in Postgresql

On Mon, Mar 17, 2014 at 9:22 PM, Rajmohan C csrajmo...@gmail.com wrote: I am implementing Planner hints in Postgresql to force the optimizer to select a particular plan for a query on request from sql input. I am having trouble in modifying the planner code. I want to create a path node of

Re: [HACKERS] Planner hints in Postgresql

On Mon, Mar 17, 2014 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: David Johnston pol...@yahoo.com writes: Need to discuss the general why before any meaningful help on the how is going to be considered by hackers. Possibly worth noting is that in past discussions, we've concluded that

Re: [HACKERS] Planner hints in Postgresql

On Mon, Mar 17, 2014 at 10:58 PM, Stephen Frost sfr...@snowman.net wrote: * Atri Sharma (atri.j...@gmail.com) wrote: Isnt using a user given value for selectivity a pretty risky situation as it can horribly screw up the plan selection? Why not allow the user to specify an alternate plan

Re: [HACKERS] Planner hints in Postgresql

The larger question to answer first is whether we want to implement something that is deterministic... How about just dropping the whole concept of hinting and provide a way for someone to say use this plan, or die trying. Maybe require it be used in conjunction with named PREPAREd

Re: [HACKERS] Planner hints in Postgresql

There's lots of ways to implement planner hints, but I fail to see the point in discussing how to implement something we actively don't want. +1. The original poster wanted a way to implement it as a personal project or something ( I think he only replied to me, not the entire list). Planner

Re: [HACKERS] Planner hints in Postgresql

On Mon, Mar 17, 2014 at 10:54 PM, Tom Lane t...@sss.pgh.pa.us wrote: Atri Sharma atri.j...@gmail.com writes: On Mon, Mar 17, 2014 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: Possibly worth noting is that in past discussions, we've concluded that the most sensible type of hint would

Re: [HACKERS] Planner hints in Postgresql

There's a big difference between saying to the planner, Use plan X vs Here's some information describing the data supporting choosing plan X intelligently. The latter allows for better plans in the face of varied/changing data, integrates with the planner in natural way, and encourages users

  1   2   3   4   >