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 GSoC.
> 2. In 2016 GSoC applicat
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. Currently PostgreSQL doesn't handle such a use case well.
>
>
> Yeah, I have a
>
>
>
> 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 utili
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 Pavel
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, here
> are more direct
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. https://commitfest.postgresql.org/8/
>
> We have two committed
On Mon, Jan 11, 2016 at 10:48 PM, Atri Sharma 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,
>
> Atri
>
> On Tue, J
On Tue, Jan 5, 2016 at 11:09 AM, Tom Lane wrote:
> Atri Sharma 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
> inside
> > executor and its fail safety.
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 wrote:
> On 2016/01/05 14:30, Atri Sharma wrote:
> > On Tue, Ja
On Tue, Jan 5, 2016 at 9:54 AM, Amit Langote
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 functions"? Is it "Plan" nod
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" wrote:
> On 1/4/16 12:07 PM, Atri Sharma wrote:
>
>> Hi All,
>>
>> I wanted to check if it is possib
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
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: Increase the configuration para
> 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 o
> 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 i
On Thu, Aug 13, 2015 at 12:55 PM, Pavel Stehule
wrote:
>
>
> 2015-08-13 9:21 GMT+02:00 Marko Tiikkaja :
>
>> 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 num_nonulls()?
>
>
+1
>
> * Unique Joins
>>
>
> Still needs to be reviewed. Any volunteers?
>
>
>
Can take this one up, if its within my limits.
On 31 Jul 2015 11:59, "Tatsuo Ishii" wrote:
>
> > On 31 Jul 2015 10:15, "Tatsuo Ishii" 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
> >> > immediate use for
On Wed, Jul 15, 2015 at 12:57 PM, Jeff Davis 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 internal data ty
On Wed, Jun 10, 2015 at 2:16 PM, Amit Langote 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.
On Fri, May 29, 2015 at 12:59 AM, Merlin Moncure wrote:
> On Wed, May 27, 2015 at 3:06 PM, boix 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,
> > actually we are trying with a
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 a/doc
I am up for mentoring again.
On 10 Feb 2015 02:23, "Thom Brown" 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 student
On Mon, Feb 2, 2015 at 6:34 PM, Pavel Stehule
wrote:
>
>
> 2015-02-02 13:36 GMT+01:00 Atri Sharma :
>
>>
>>> > 1. Main catalogue will be stable.
>>> > 2. There is not necessary to implement new storage and it can helps
>>> with
>>> &g
>
>
> > 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
> 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 w
On Tuesday, January 6, 2015, Amit Langote
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
> >> wrote:
> >> Though, I have no strong opinion on whether one thing is good
On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote wrote:
> On 06-01-2015 PM 04:08, Atri Sharma wrote:
> > On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp
>
>
> I read what Ashutosh says as that a clause like IMMUTABLE does not
> entail a nod
On Tue, Jan 6, 2015 at 12:47 PM, Pavan Deolasee
wrote:
>
>
> On Tue, Jan 6, 2015 at 12:38 PM, Atri Sharma wrote:
>
>>
>>
> May be what Amit has in mind is that the planner can choose the most
> optimal sorting algorithm using the hint that the dataset is probably
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 wrote:
>
>>
>>>>
>>>>
>>>> Even checking whether the output of the function is in the rig
On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote wrote:
> On 06-01-2015 PM 04:00, Ashutosh Bapat wrote:
> > On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma
> wrote:
> >>> We can eliminate the new node and put onus or having the right order on
> >>> the user lik
>
>
>>
>> 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 elim
On Mon, Jan 5, 2015 at 11:24 PM, Tom Lane wrote:
> David G Johnston 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;
>
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
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 i
On Tue, Dec 23, 2014 at 3:06 PM, Ravi Kiran
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
> mysql, I want to u
On Tuesday, December 23, 2014, Robert Haas wrote:
> On Mon, Dec 22, 2014 at 11:19 AM, Andrew Gierth
> > 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 frames,
> > Tom> whereas we have to expect that the
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 wrote:
> >
> >
> > Another thought I had was to suggest we consider *everyone* to be a
> > contributor and implement a way to tie together the mailing lis
On Wed, Dec 17, 2014 at 7:18 PM, Simon Riggs wrote:
>
> On 17 December 2014 at 12:35, Kouhei Kaigai 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
> > of the aggregate function. In
On Wed, Dec 17, 2014 at 6:05 PM, Kouhei Kaigai 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 performs like
> tr
On Wed, Dec 17, 2014 at 3:23 PM, Simon Riggs 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 a
> semantical
On Wed, Dec 17, 2014 at 12:03 AM, Stephen Frost 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 the challe
On Mon, Dec 8, 2014 at 6:06 AM, Michael Paquier
wrote:
>
> On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane 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
> > seems to be trying to skate by with
On Wed, Dec 3, 2014 at 11:47 PM, Tom Lane wrote:
> Atri Sharma writes:
> > On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane wrote:
> >> I think the right approach for now is to emulate the GEQO precedent as
> >> closely as possible. Build all the single-relation Paths the
On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane wrote:
> Stephen Frost 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 i
On Wed, Dec 3, 2014 at 11:27 PM, Stephen Frost 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).
&
On Wed, Dec 3, 2014 at 11:19 PM, Tom Lane wrote:
> Atri Sharma 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 and above)
On Wed, Dec 3, 2014 at 11:03 PM, Tom Lane wrote:
> Stephen Frost 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
> >> one case or the other.
On Wed, Dec 3, 2014 at 8:32 PM, Stephen Frost 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 ex
On Wed, Dec 3, 2014 at 5:00 PM, Simon Riggs wrote:
> On 3 December 2014 at 09:29, David Rowley wrote:
> > *** Method 3: Marking scans as possibly skippable during planning and
> > removing redundant join nodes at executor startup (Simon's method)
> >
> > Pros:
> > 1. The plan can be executed as
On Wed, Nov 12, 2014 at 1:24 PM, David Rowley wrote:
>
> On Tue, Nov 11, 2014 at 9:29 PM, Simon Riggs
> 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 SELECT count(*) FROM foo to go
On Saturday, November 8, 2014, Tom Lane 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 the names of
On Fri, Nov 7, 2014 at 7:15 PM, Robert Haas wrote:
> On Wed, Nov 5, 2014 at 8:24 AM, Atri Sharma 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
> and
>
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 col
On Sun, Nov 2, 2014 at 3:40 PM, rohtodeveloper
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 )
>
> However, In Postgre
>
>
>
> 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
> b
On Mon, Oct 27, 2014 at 4:44 PM, Heikki Linnakangas 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
>
>
>>
> 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 th
On Fri, Oct 17, 2014 at 7:45 PM, Merlin Moncure wrote:
> On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
> >
> >
> > On Wednesday, October 15, 2014, Marti Raudsepp wrote:
> >>
> >> Hi
> >>
> >> On Wed, Oct 15, 2014 at 11:02 AM,
On Wed, Oct 15, 2014 at 2:18 PM, Atri Sharma wrote:
>
> On Wednesday, October 15, 2014, Marti Raudsepp wrote:
>
>> Hi
>>
>> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma
>> wrote:
>> > Please find attached a patch which implements support for UPD
On Wednesday, October 15, 2014, Marti Raudsepp wrote:
> Hi
>
> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma > wrote:
> > Please find attached a patch which implements support for UPDATE table1
> > SET(*)=...
>
> I presume you haven't read Tom Lane's
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 foo
On Tue, Sep 30, 2014 at 11:06 AM, Tom Lane wrote:
> Shay Rojansky writes:
> > Thanks for the suggestion to look at PgJDBC, I'll do that.
>
> BTW, libpqtypes (http://libpqtypes.esilo.com) might be worth
> studying as well. I've not used it myself, but it claims to
> offer datatype-extensible pro
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
>> mailto:mark.kirkw...@catalyst.net.nz>>
>>
>>
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
>> mailto:mark.kirkw...@catalyst.net.nz>>
>>
>>
On Sunday, September 14, 2014, Mark Kirkwood
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 version
>> of sa
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 <
>
>
>
> Or rather even if you want to be able to reference the older versions of
> that record
On Sat, Sep 13, 2014 at 11:06 PM, 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 version of
> salary.
>
> I want to select salary of person nam
On Fri, Sep 5, 2014 at 2:20 AM, Robert Haas wrote:
> On Thu, Sep 4, 2014 at 11:56 AM, Bruce Momjian 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 statistics get outdated
On Thu, Sep 4, 2014 at 9:33 PM, Bruce Momjian 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 als
On Thu, Sep 4, 2014 at 9:26 PM, Bruce Momjian wrote:
> On Thu, Sep 4, 2014 at 08:41:43PM +0530, Atri Sharma wrote:
> >
> >
> > On Thursday, September 4, 2014, Bruce Momjian wrote:
> >
> > On Thu, Sep 4, 2014 at 08:37:08AM -0400, Robert Haas wrote:
> &g
On Thursday, September 4, 2014, Bruce Momjian 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 asking th
On Sunday, August 31, 2014, Andres Freund wrote:
> On 2014-08-31 21:09:59 +0530, Atri Sharma wrote:
> > On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers > wrote:
> > > I have found that the "unrecognized node type" error is caused by:
>
>
On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers wrote:
> On Tue, August 26, 2014 14:24, Andrew Gierth wrote:
> >> "Erik" == Erik Rijkers writes:
> >
> > >> They apply cleanly for me at 2bde297 whether with git apply or
> > >> patch, except for the contrib one (which you don't need unless you
On Saturday, August 30, 2014, Amit Kapila wrote:
> On Sat, Aug 30, 2014 at 11:56 AM, Jeff Janes > wrote:
> >
> > If you insert tuples with COPY into a table created or truncated in the
> same transaction, at the end of the COPY it calls heap_sync.
> >
> > But there cases were people use COPY in
On Thu, Aug 14, 2014 at 10:21 PM, Tomas Vondra wrote:
> On 14 Srpen 2014, 18:02, Atri Sharma wrote:
> > On Thursday, August 14, 2014, Jeff Davis wrote:
> >
> >> On Thu, 2014-08-14 at 10:06 -0400, Tom Lane wrote:
> >> > If you're following the Has
On Thursday, August 14, 2014, Jeff Davis 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 now conta
On Tuesday, July 22, 2014, Rohit Goyal 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 to use top m
On Tue, Jul 22, 2014 at 10:53 AM, Rajmohan C 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
On Thu, Jul 3, 2014 at 11:40 PM, Stephen Frost 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 wasn't).
On Tue, Jul 1, 2014 at 4:54 AM, Tomas Vondra 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 pr
On Mon, Jun 16, 2014 at 11:28 AM, Michael Paquier wrote:
> On Mon, May 26, 2014 at 6:23 AM, Ronan Dunklau
> 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,
> >> >
> >> > Since my last proposal di
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 hi
On Fri, May 2, 2014 at 10:07 AM, Rajmohan C 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*
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
On Tue, Apr 22, 2014 at 12:59 PM, Albe Laurenz wrote:
> 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 actually track the
On Sat, Apr 19, 2014 at 3:37 AM, Bruce Momjian 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 traversal to
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 transa
On Sat, Apr 19, 2014 at 1:07 AM, Bruce Momjian 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 buff
On Fri, Apr 18, 2014 at 7:27 AM, Peter Geoghegan 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 spread across mu
On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule wrote:
>
>
>
> 2014-04-07 11:59 GMT+02:00 Rajeev rastogi :
>
> On 07 April 2014 12:12, Pavel Stehule wrote:
>>
>> >+1 for feature
>>
>> Thanks
>>
>>
>>
>> >-1 for Oracle syntax - it is hardly inconsistent with Postgres
>>
>> We can discuss and come
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*
On Thu, Mar 20, 2014 at 8:51 PM, Tom Lane wrote:
> Atri Sharma 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 to be b
On Thu, Mar 20, 2014 at 8:10 PM, Robert Haas wrote:
> On Tue, Mar 18, 2014 at 2:41 PM, Tom Lane wrote:
> > Atri Sharma writes:
> >> One of the factors that leads to bad estimates is that the histogram of
> the
> >> values of a column maintained by the planner g
>
>> > 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 ty
On Tue, Mar 18, 2014 at 11:43 PM, Josh Berkus wrote:
>
> > On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane 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 it to prefer low-uncert
On Tue, Mar 18, 2014 at 12:46 AM, Merlin Moncure wrote:
> On Mon, Mar 17, 2014 at 1:45 PM, Pavel Stehule
> wrote:
> > I don't believe so SELECTIVITY can work well too. Slow queries are
> usually
> > related to some strange points in data. I am thinking so well concept
> should
> > be based on va
On Mon, Mar 17, 2014 at 11:50 PM, Merlin Moncure wrote:
> On Mon, Mar 17, 2014 at 12:57 PM, Atri Sharma wrote:
> >
> >> There's a big difference between saying to the planner, "Use plan X"
> >> vs "Here's some information describing the data
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
On Mon, Mar 17, 2014 at 10:54 PM, Tom Lane wrote:
> Atri Sharma writes:
> > On Mon, Mar 17, 2014 at 9:45 PM, Tom Lane wrote:
> >> Possibly worth noting is that in past discussions, we've concluded that
> >> the most sensible type of hint would not be "us
1 - 100 of 360 matches
Mail list logo
