Re: [HACKERS] Road map to study about fetching a set of tuples - novice!

Sent from my iPad On 18-May-2013, at 20:01, Soroosh Sardari wrote: > Hi > > I was tracing a simple SELECT query to find how pg works for fetching tuples. > but I'm totally lost in the code. > Could you help me to understand under the hood? > I know about parsing and planning parts, my actual

Re: [HACKERS] Road map to study about fetching a set of tuples - novice!

Sent from my iPad On 18-May-2013, at 20:49, "Dickson S. Guedes" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Em 18-05-2013 11:40, Atri Sharma escreveu: >> On 18-May-2013, at 20:01, Soroosh Sardari >> wrote: >> >>> Hi >>

Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

Sent from my iPad On 20-May-2013, at 18:14, Amit Langote wrote: > Wonder though if this question is better asked in pgsql-novice? > > On Mon, May 20, 2013 at 9:23 PM, Amit Langote wrote: >> Hello, >> >> I think a more appropriate question to be asked here would be at what >> point (in the l

Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

On Mon, May 20, 2013 at 8:54 PM, Alvaro Herrera wrote: > Hello, > > Would you guys please trim the quoted text of the emails you're replying > to? I understand Gmail is obnoxious w.r.t. quoted text, but this is > starting to become excessive. Oops, I didnt notice that. Sorry! Regards, Atri -

[HACKERS] Time limit for a process to hold Content lock in Buffer Cache

Hi all, I was searching for an existing mechanism which ensures that a crashed process releases a content lock held on a page in buffer cache. Also, a similar mechanism for refcount of the page. I seem to have missed it. Do we have a mechanism,and if yes,where can I find it? Regards, Atri -- R

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

Sent from my iPad On 23-May-2013, at 16:27, Amit Kapila wrote: > On Thursday, May 23, 2013 3:35 PM Atri Sharma wrote: >> Hi all, >> >> I was searching for an existing mechanism which ensures that a crashed >> process releases a content lock held on a page in buffe

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

On Thu, May 23, 2013 at 8:01 PM, Tom Lane wrote: > Atri Sharma writes: >> On a different note, shouldn't we have a time out for a content lock >> in buffer cache? > > No; the overhead of setting up and canceling such a timeout would > greatly outweigh any possible be

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

On Thu, May 23, 2013 at 8:18 PM, Tom Lane wrote: > Atri Sharma writes: >> I was musing over a possible condition where a rogue client gets the >> backend to process queries which take a *lot* of time(note, this is >> only in my head atm.I may be completely wrong here). >

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

> For instance, take out exclusive locks on all your tables and just > go to sleep (although I think this is limited by table permissions in > recent PG versions). This is what I have been worried about. The locks(exclusive locks or content locks in buffers) can be held and stalled. Cant we do any

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

> No, you're not following. These would be table-level heavyweight locks, > and there already are timeout mechanisms that work at that level. > Oh,right.Sorry,I missed that. I will go and research heavyweight locks now. Thanks a ton! Regards, Atri -- Regards, Atri l'apprenant -- Sent via

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

On Thu, May 23, 2013 at 8:52 PM, Amit Langote wrote: >> >> If you let an uncooperative user issue arbitrary SQL queries, he can >> do any number of things to put server performance into the tank. >> For instance, take out exclusive locks on all your tables and just >> go to sleep (although I think

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

> > A little bit --- the timeout won't actually kill the query until the > next time control reaches a CHECK_FOR_INTERRUPTS macro that's not inside > a critical section. We've had issues in the past with particular code > paths that failed to include such a check in a long-running loop, and > ther

Re: [HACKERS] Time limit for a process to hold Content lock in Buffer Cache

> Right, the actual signal handler will only kill the query immediately > if the backend is in a safe state (eg, while it's waiting for a > heavyweight lock). Otherwise it just sets a flag that's checked by > CHECK_FOR_INTERRUPTS. See StatementCancelHandler in postgres.c. Roger that, I will defi

Re: [HACKERS] PostgreSQL Process memory architecture

> Does each PostgreSQL process allocating in its own memory (Not shared > memory) a cache of all the database catalog which it access during the SQL > execution? > > I mean does each process holds all the catalog indexes data which it > accessed, all the catalog index statistics etc’ accessed AFAI

Re: [HACKERS] PostgreSQL Process memory architecture

On Mon, May 27, 2013 at 3:41 PM, Ben Zeev, Lior wrote: > Hi Atri, > > Thanks for your answer! > Do you have idea what may be the reason that PostgreSQL process consume more > memory when there are more partial indexes on the DB table? Well, I am not too sure, but indexes always take up more spa

Re: [HACKERS] PostgreSQL Process memory architecture

On Mon, May 27, 2013 at 3:55 PM, Ben Zeev, Lior wrote: > Thanks Atri! > > Do you know why PostgreSQL store the indexes in memory per process and not in > the shared memory? > Is there a way to prevent it store the indexes data per process, and force it > storing it in the shared memory? Ok, so

Re: [HACKERS] PostgreSQL Process memory architecture

> An index is built in backend process's local memory, but, when > accessing, index pages are stored in shared memory. That is, for > example, when an index scan is performed, index pages are brought into > shared memory and accessed from there. > > Yes, brought into the shared disk buffers and re

Re: [HACKERS] PostgreSQL Process memory architecture

>> AFAIK, the shared disk buffers are the only part shared between the >> processes. > > There's a bit of other information shared, but disk buffers are > certainly the bulk of it. The other information being locks? Regards, Atri -- Regards, Atri l'apprenant -- Sent via pgsql-hackers maili

Re: [HACKERS] PostgreSQL Process memory architecture

> A better place to look would be the documentation for the release of PG > which you are on, or the latest release otherwise, which is: > > http://www.postgresql.org/docs/9.2/static/storage.html Oops,yes,sorry about that. Thanks a ton for pointing that out. Regards, Atri -- Regards, Atri l'

Re: [HACKERS] PostgreSQL Process memory architecture

> This is not generally a reason to avoid indexes. Indexes require more > disk space and must be kept up to date, making them expensive to > maintain due to increased disk i/o. Building an index uses as much > memory as it's allowed to- it uses maintenance_work_mem to limit itself. Yes, too many

Re: [HACKERS] PostgreSQL Process memory architecture

> I'd expect the performance issue would be from planner time more than > memory usage- but if there is a serious memory usage issue here, then > it'd be valuable to have a test case showing what's happening. We may > not be releasing the sys cache in some cases or otherwise have a bug in > this a

Re: [HACKERS] PostgreSQL Process memory architecture

On Mon, May 27, 2013 at 6:02 PM, Ben Zeev, Lior wrote: > Hi Stephen, > > The case which I'm seeing is that I have an empty table without any rows, > Create table test ( > Num Integer, > C1 character varying(512), > C2 character varying(512), > C3 character varying(512)); > > I create sever

Re: [HACKERS] PostgreSQL Process memory architecture

>We may still be able to do better than what we're doing > today, but I'm still suspicious that you're going to run into other > issues with having 500 indexes on a table anyway. +1. I am suspicious that the large number of indexes is the problem here,even if the problem is not with book keeping

Re: [HACKERS] 9.4 CF1 Starts Saturday: need patches, reviewers, asst. CFM

On Tue, Jun 11, 2013 at 11:46 PM, Stephen Frost wrote: > Josh, > > * Josh Berkus (j...@agliodbs.com) wrote: >> We already have 72 patches pending. > > Fun! > >> If you are available to do CF reviews, and want to be assigned a patch >> instead of choosing one for yourself, then please join the >> p

Re: [HACKERS] Hardware donation

On Fri, Jun 21, 2013 at 10:18 PM, Jim Nasby wrote: > We've got some recently decommissioned servers and Enova is willing to > donate 2 of them to the community. > > There's nothing terribly spectacular about the servers except for memory. We > have one 512G server available and the other would be

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Mon, Jun 24, 2013 at 10:54 PM, Josh Berkus wrote: > >>> I will be more than happy to resign as CFM and turn it over to someone >>> else if people have a problem with it. >> >> Heck, Josh. People have to be allowed to critize *a small part* of your >> work without you understanding it as a funda

[HACKERS] Bloom Filter lookup for hash joins

Hi All, I have been researching bloom filters and discussed it on IRC with RhodiumToad and David Fetter, and they pointed me to the various places that could potentially have bloom filters, apart from the places that already have them currently. I have been reading the current implementation of h

Re: [HACKERS] Bloom Filter lookup for hash joins

On Wed, Jun 26, 2013 at 2:09 PM, Pavel Stehule wrote: > Hello > > it looks interesting - please, try to send some performance results, > > Regards > > Pavel Hi, Sure. I will think more about it and put up a design on the list soon. My current aim would be to work on hash joins. If it works well

Re: [HACKERS] Kudos for Reviewers -- straw poll

For me, B,B and another B works. Regards, Atri -- Regards, Atri l'apprenant -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bloom Filter lookup for hash joins

> One idea that I had was to use them to do CLOG lookups from smaller > datastructures. You could store the list of aborted xids in bloom > filters. When a xid is not found in the filter, then it is known to > have committed, if the filter returns true, then you have to check the > real CLOG. This

Re: [HACKERS] Bloom Filter lookup for hash joins

On Wed, Jun 26, 2013 at 5:47 PM, Simon Riggs wrote: > On 26 June 2013 07:46, Atri Sharma wrote: > >> >> I have been researching bloom filters and discussed it on IRC with >> RhodiumToad and David Fetter, and they pointed me to the various >> places that could

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

On Sun, Jun 23, 2013 at 8:41 PM, Heikki Linnakangas wrote: > On 23.06.2013 01:48, Simon Riggs wrote: >> >> On 22 June 2013 21:40, Stephen Frost wrote: >> >>> I'm actually not a huge fan of this as it's certainly not cheap to do. If >>> it >>> can be shown to be better than an improved heuristic t

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

On Wed, Jun 26, 2013 at 7:12 PM, Stephen Frost wrote: > Atri, > > * Atri Sharma (atri.j...@gmail.com) wrote: >> I just popped in here on Simon's advice to put an idea I had about >> optimizing hash joins on this thread. > > I'd encourage reading the thread a

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

On Wed, Jun 26, 2013 at 9:20 PM, Stephen Frost wrote: > * Atri Sharma (atri.j...@gmail.com) wrote: >> My point is that I would like to help in the implementation, if possible. :) > > Feel free to go ahead and implement it.. I'm not sure when I'll have a > chance to (p

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

> > Isn't it currently the last week of this month? :) I'm guessing you > mean July. Heh,no.I lose track of time these days. Alright, second week of July then. > I really don't see that happening, to be honest.. I think it would be > interesting to try some of the surrogate-additional-hashing

Re: [HACKERS] Bloom Filter lookup for hash joins

On Thu, Jun 27, 2013 at 12:01 AM, Jeff Janes wrote: > I don't think that sounds all that promising. When the hash table does not > fit in memory, it is either partitioned into multiple passes, each of which > do fit in memory, or it chooses a different plan altogether. Yeah, my point is, we cou

[HACKERS] Group Commits Vs WAL Writes

Hi all, I think this is a naive question. When we do a commit, WAL buffers are written to the disk. This has a disk latency for the required I/O. Now, with group commits, do we see a spike in that disk write latency, especially in the cases where the user has set wal_buffers to a high value? R

Re: [HACKERS] Group Commits Vs WAL Writes

> > commit_delay exists to artificially increase the window in which the > leader backend waits for more group commit followers. At higher client > counts, that isn't terribly useful because you'll naturally have > enough clients anyway, but at lower client counts particularly where > fsyncs have h

Re: [HACKERS] Group Commits Vs WAL Writes

> Well, it does take longer to fsync a larger byte range to disk than a > smaller byte range, in some cases. But it's generally more efficient > to write one larger range than many smaller ranges, so you come out > ahead on the whole. Right, that does make sense. So, the overhead of writing a lo

Re: [HACKERS] Group Commits Vs WAL Writes

> > There is a spot on the disk to which the current WAL is destined to go. > That spot on the disk is not going to be under the write-head for (say) > another 6 milliseconds. > > Without commit_delay, I try to commit my record, but find that someone else > is already on the lock (and on the fsync

Re: [HACKERS] Group Commits Vs WAL Writes

> > Yep. To take a degenerate case, suppose that you had many small WAL > records, say 64 bytes each, so more than 100 per 8K block. If you > flush those one by one, you're going to rewrite that block 100 times. > If you flush them all at once, you write that block once. > > But even when the ran

[HACKERS] Randomisation for ensuring nlogn complexity in quicksort

Hi all, I have been reading the recent discussion and was researching a bit, and I think that we should really go with the idea of randomising the input data(if it is not completely presorted), to ensure that we do not get quadratic complexity. One easy way to do that could be to take a sample

Re: [HACKERS] Randomisation for ensuring nlogn complexity in quicksort

On Mon, Jul 1, 2013 at 10:02 PM, David Fetter wrote: > On Mon, Jul 01, 2013 at 04:42:04AM -0700, jasmine wrote: >> My PostgresSQL (9.2) is crashing after certain load tests. Currently, >> postgressql is crashing when simulatenously 800 to 1000 threads are run on a >> 10 million records schema. Not

Re: [HACKERS] Randomisation for ensuring nlogn complexity in quicksort

On Tue, Jul 2, 2013 at 1:02 AM, Robert Haas wrote: > On Sun, Jun 30, 2013 at 8:30 AM, Atri Sharma wrote: >> I have been reading the recent discussion and was researching a bit, and I >> think that we should really go with the idea of randomising the input >> data(if

Re: [HACKERS] Randomisation for ensuring nlogn complexity in quicksort

On Tue, Jul 2, 2013 at 5:20 PM, Robert Haas wrote: > On Tue, Jul 2, 2013 at 12:33 AM, Atri Sharma wrote: >>> If you want to get a useful response to your emails, consider >>> including a statement of what you think the problem is and why you >>> think your propose

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

Hi all, I have been working on a patch for the above discussed functionalities. I made an array of int32s, one for each bucket in a hash table(the array is per hash table). I am using the hash value directly to set the corresponding bit in the bit field.Specifically: bitfield_orvalue = 1

Re: [HACKERS] Grouping Sets

On Thu, Jul 4, 2013 at 6:56 PM, Dev Kumkar wrote: > On Thu, Jul 4, 2013 at 6:31 PM, Pavel Stehule > wrote: >> >> Hello >> >> >> I don't work on this topic now, and my code is not usable for production. > > > Ok, no problem. Will await for any other pointers regarding any related > patch here. > >

Re: [HACKERS] Should we automatically run duplicate_oids?

On Tue, Jul 9, 2013 at 6:55 AM, Peter Geoghegan wrote: > When rebasing a patch that I'm working on, I occasionally forget to > update the oid of any pg_proc.h entries I may have created. Of course > this isn't a real problem; when I go to initdb, I immediately > recognize what has happened. All th

[HACKERS] Removing Inner Joins

Hi all, I was reading about the plans to add functionality to the planner to remove redundant inner joins where there is no member of the inner relation present in the target list and the inner relation is only used for the join clause. Also, we have a foreign key in the outer relation to the inne

Re: [HACKERS] Removing Inner Joins

On Tue, Jul 9, 2013 at 12:01 PM, Peter Geoghegan wrote: > On Mon, Jul 8, 2013 at 11:20 PM, Atri Sharma wrote: >> Where are we with that functionality atm? Do we have plans to move forward? > > PostgreSQL has had this capability for some time. See: > > http://git.pos

Re: [HACKERS] Removing Inner Joins

My main point here is researching how difficult it is to add functionality in the planner to allow it to to detect and make decisions on foreign keys present in the outer relation. I think that if this is added, rest of the work would be much easier. I amy be completely wrong,though. Thoughts/Com

Re: [HACKERS] [REVIEW] row level security (v3)

On Wed, Jul 10, 2013 at 12:58 AM, Mike Blackwell wrote: > The most recent patch (v3) applies and builds cleanly and passes make check. > Documentation on the new SQL syntax and catalog changes is included with the > patch and looks good to me. > > The regression tests look pretty complete. In add

Re: [HACKERS] Removing Inner Joins

On Wed, Jul 10, 2013 at 8:29 AM, Ashutosh Bapat wrote: > AFAIK, > There is code to remove the redundant relations (joins too are relations). > But I don't remember exactly where it is. Start looking at query_planner(). > The removal of relations should happen before actually planning the joins. >

Re: [HACKERS] Removing Inner Joins

> Can you please post an example of such a join removal? I mean a query before > and after the removal. Thanks, Courtesy Robert Haas: SELECT foo.x, foo.y, foo.z FROM foo WHERE foo.x = bar.x Conditions: 1) foo.x is not null. 2) foo (x) is a foreign key referencing bar (x). We can ignore bar co

Re: [HACKERS] Removing Inner Joins

On Wed, Jul 10, 2013 at 1:11 PM, Hannu Krosing wrote: > On 07/10/2013 09:18 AM, Atri Sharma wrote: >>> Can you please post an example of such a join removal? I mean a query before >>> and after the removal. Thanks, >> Courtesy Robert Haas: >> >> SELECT f

Re: [HACKERS] Removing Inner Joins

Sent from my iPad On 10-Jul-2013, at 13:11, Hannu Krosing wrote: > On 07/10/2013 09:18 AM, Atri Sharma wrote: >>> Can you please post an example of such a join removal? I mean a query before >>> and after the removal. Thanks, >> Courtesy Robert Haas: >> >&

Re: [HACKERS] Removing Inner Joins

Sent from my iPad On 14-Jul-2013, at 22:12, Hannu Krosing wrote: > On 07/14/2013 06:10 PM, Atri Sharma wrote: >> >> Sent from my iPad >> >> On 10-Jul-2013, at 13:11, Hannu Krosing wrote: >> >>> On 07/10/2013 09:18 AM, Atri Sharma wrote: >>&

[HACKERS] Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)

On Thu, Jul 18, 2013 at 10:02 AM, David Fetter wrote: > On Thu, Jul 18, 2013 at 03:15:14AM +, Andrew Gierth wrote: >> The spec defines two types of aggregate function classed as "ordered set >> function", as follows: >> >> 1. An "inverse distribution function" taking one argument (which must b

Re: [HACKERS] create index does change pages?

Sent from my iPad On 20-Jul-2013, at 15:26, mohsen soodkhah mohammadi wrote: > hello. > dose one create index on the large table changes the place of some tuples in > some pages? No, making an index involves keeping some metadata about your tables in an auxiliary data structure. It will r

Re: [HACKERS] [v9.4] row level security

> (This is a bit much to expect new reviewers to chew on usefully) I've been > working on that here, but I don't have anything I can publicly commit to > yet. > True that. I spent some time on it, but couldn't come up with anything useful. Mike's extensive testing seems good enough for me, thoug

Re: [HACKERS] Bloom Filter lookup for hash joins

On Tue, Jul 23, 2013 at 7:32 PM, Greg Stark wrote: > This exact idea was discussed a whole back. I think it was even implemented. > > The problem Tom raised at the time is that the memory usage of the bloom > filter implies smaller or less efficient hash table. It's difficult to > determine whethe

Re: [HACKERS] replication_reserved_connections

Sent from my iPad On 28-Jul-2013, at 5:53, Marko Tiikkaja wrote: > Hi, > > Yesterday an interesting scenario was diagnosed on IRC. If you're running a > synchronous slave and the connection to the slave is lost momentarily, your > backends start naturally waiting for the slave to reconnect

Re: [HACKERS] Should we automatically run duplicate_oids?

Sent from my iPad On 02-Aug-2013, at 10:30, Bruce Momjian wrote: > On Mon, Jul 8, 2013 at 06:25:44PM -0700, Peter Geoghegan wrote: >> When rebasing a patch that I'm working on, I occasionally forget to >> update the oid of any pg_proc.h entries I may have created. Of course >> this isn't a re

Re: [HACKERS] query_planner() API change

> While we could complicate query_planner()'s API even more to add some > understanding of unnecessary resjunk items, I think this is probably > the straw that breaks the camel's back for the current approach here. > There is already a comment like this in query_planner(): > > * This introduce

Re: [HACKERS] StrategyGetBuffer optimization, take 2

> optimization 2: refcount is examined during buffer allocation without > a lock. if it's > 0, buffer is assumed pinned (even though it may not > in fact be) and sweep continues +1. I think this shall not lead to much problems, since a lost update cannot,IMO, lead to disastrous result. At most,

Re: [HACKERS] query_planner() API change

On Mon, Aug 5, 2013 at 6:19 PM, Tom Lane wrote: > Atri Sharma writes: >>> While we could complicate query_planner()'s API even more to add some >>> understanding of unnecessary resjunk items, I think this is probably >>> the straw that breaks the camel&#

Re: [HACKERS] COPY and heap_sync

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

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

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

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

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: > >

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

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

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

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

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

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

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

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

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

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

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 < > > > > Or rather even if you want to be able to reference the older versions of > that record

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

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

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 >> mailto:mark.kirkw...@catalyst.net.nz>> >> >>

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 >> mailto:mark.kirkw...@catalyst.net.nz>> >> >>

Re: [HACKERS] Proper query implementation for Postgresql driver

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

[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 foo

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

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

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

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

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

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,

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 th

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

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

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 > b

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

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

[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 col

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

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 >

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

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

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

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

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 o

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: Increase the configuration para

[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] 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" wrote: > On 1/4/16 12:07 PM, Atri Sharma wrote: > >> Hi All, >> >> I wanted to check if it is possib

Re: [HACKERS] Accessing non catalog table in backend

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

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 wrote: > On 2016/01/05 14:30, Atri Sharma wrote: > > On Tue, Ja

Re: [HACKERS] Accessing non catalog table in backend

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.

Re: [HACKERS] Accessing non catalog table in backend

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

Re: [HACKERS] [v9.3] writable foreign tables

Awesome. I would love to implement this API in JDBC_FDW. Atri Sent from my iPad On 16-Nov-2012, at 20:20, "Albe Laurenz" wrote: > Kohei KaiGai wrote: >> The attached patch is just a refreshed version for clean applying to >> the latest tree. >> >> As previous version doing, it makes pseudo e

<    1   2   3   4   >