Re: [HACKERS] Doubt in 9.5 release note

On Wed, Jan 27, 2016 at 01:31:45PM +0900, Tatsuo Ishii wrote: > > Tatsuo Ishii writes: > >> I saw following item in release-9.5.sgml: > >> > >> > >> Support comments on domain > >> constraints (Álvaro Herrera) > >> > >> > > > >> It seems the release note ha

Re: [HACKERS] Doubt in 9.5 release note

> Tatsuo Ishii writes: >> I saw following item in release-9.5.sgml: >> >> >> Support comments on domain >> constraints (Álvaro Herrera) >> >> > >> It seems the release note has nothing to do with the commit. Also, >> commenting on DOMAIN constraints is not

Re: [HACKERS] Doubt in 9.5 release note

Tatsuo Ishii writes: > I saw following item in release-9.5.sgml: > > > Support comments on domain > constraints (Álvaro Herrera) > > > It seems the release note has nothing to do with the commit. Also, > commenting on DOMAIN constraints is not new in 9.5, I

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tatsuo, So on second thought the formula should rather be: ... / (is_connect? nclients: nthreads) I don't think this is quite correct. If is_connect is false, then following loop is executed in threadRun(): /* make connections to the database */ for

Re: [HACKERS] Doubt in pgbench TPS number

>> FWIW, I vote with Tatsuo-san. Such a change will break comparability of >> results with all previous versions, which means it's not something to do >> in minor releases, even if we now believe the previous results were >> somewhat bogus. Arguing that it's "not a behavioral change" seems >> qui

Re: [HACKERS] Doubt in pgbench TPS number

>> Here conn_total_time is the sum of time to establish connection to >> PostgreSQL. Since establishing connections to PostgreSQL is done in >> serial rather than in parallel, conn_total_time should have been >> divided by nclients. > > After some more thinking and looking again at the connection

Re: [HACKERS] Doubt in pgbench TPS number

(Note: I've not read the patch, so this is not an opinion about its correctness.) As Fabien anayzed the problem was that pgbench simply uses wrong variable: nthreads (number of threads, specified by "-j" option) vs. nclients (number of clients, specified by "-c" option). @@ -2616,7 +2616,7 @@

Re: [HACKERS] Doubt in pgbench TPS number

> FWIW, I vote with Tatsuo-san. Such a change will break comparability of > results with all previous versions, which means it's not something to do > in minor releases, even if we now believe the previous results were > somewhat bogus. Arguing that it's "not a behavioral change" seems > quite lo

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tom, FWIW, I vote with Tatsuo-san. Such a change will break comparability of results I would not classify a performance measure as a "result compatibility" issue. What matters is the *correction* of the results. When a bug is fixed anywhere in pg it may change performance significan

Re: [HACKERS] Doubt in pgbench TPS number

Fabien COELHO writes: >> Yeah, that's definitely a bug but I'm afraid the fix will change the >> TPS number and may break the backward compatibility. Since we have >> lived with bug for years, I hesitate to back port to older stable >> branches... > My 2¥: I do not think of a good argument to kee

Re: [HACKERS] Doubt in pgbench TPS number

>> Yeah, that's definitely a bug but I'm afraid the fix will change the >> TPS number and may break the backward compatibility. Since we have >> lived with bug for years, I hesitate to back port to older stable >> branches... > > My 2¥: I do not think of a good argument to keep wrong tps numbers >

Re: [HACKERS] Doubt in pgbench TPS number

#5 0x00402b2b in doConnect () at pgbench.c:650 #6 0x00404591 in doCustom (thread=0x25c2f40, st=0x25c2770, conn_time=0x25c2f90, logfile=0x0, agg=0x7fffba224260) at pgbench.c:1353 #7 0x0040a1d5 in threadRun (arg=0x25c2f40) at pgbench.c:3581 #8 0x00409ab4 in m

Re: [HACKERS] Doubt in pgbench TPS number

>> I'm not sure about this. I think pgbench will not start transactions >> until all clients establish connections to PostgreSQL. > > I think that is true if "!is_connect", all client connections are > performed at the beginning of threadRun, but under -C each client has > its own connect/deconnec

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tatsuo-san, I think that the degree of parallelism to consider is nclients, not nthreads: while connection time is accumulated in conn_time, other clients are possibly doing their transactions, in parallel, I'm not sure about this. I think pgbench will not start transactions until all c

Re: [HACKERS] Doubt in pgbench TPS number

> I have tested your patch. It seems the tolerance is much better than > before with your patch. [snip] > I'm going to commit your patch if there's no objection. I think we should commit this to master and 9.5 stable branch only because the fix significantly changes the benchmark result of pgben

Re: [HACKERS] Doubt in pgbench TPS number

> I think that the degree of parallelism to consider is nclients, not > nthreads: while connection time is accumulated in conn_time, other > clients are possibly doing their transactions, in parallel, I'm not sure about this. I think pgbench will not start transactions until all clients establish

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tatsuo, Hmmm... I never use -C. The formula seems ok: tps_exclude = normal_xacts / (time_include - (INSTR_TIME_GET_DOUBLE(conn_total_time) / nthreads)); Hmmm... it is not:-) I think that the degree of parallelism to consider is nclients, not nthreads: while

Re: [HACKERS] Doubt in pgbench TPS number

Hello Tatsuo-san, $ pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test tps = 95.799114 (including connections establishing) tps = 124.487149 (excluding connections establishing) Interesting thing is, the number from "excluding connections establishing". 124.487149 tps means 0.008032 seconds

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Wed, Aug 5, 2015 at 9:21 PM, Michael Paquier wrote: > > On Thu, Aug 6, 2015 at 3:06 AM, Fabrízio de Royes Mello wrote: > > On Wed, Aug 5, 2015 at 9:31 AM, Robert Haas wrote: > >> Agreed. I think we're making a mountain out of a molehill here. As > >> long as the locks that are actually used a

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Thu, Aug 6, 2015 at 3:06 AM, Fabrízio de Royes Mello wrote: > On Wed, Aug 5, 2015 at 9:31 AM, Robert Haas wrote: >> Agreed. I think we're making a mountain out of a molehill here. As >> long as the locks that are actually used are monotonic, just use > and >> stick a comment in there explainin

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Wed, Aug 5, 2015 at 9:31 AM, Robert Haas wrote: > > On Tue, Aug 4, 2015 at 1:15 PM, Alvaro Herrera wrote: > > That opens up for lock escalation and deadlocks, doesn't it? You are > > probably thinking that it's okay to ignore those but I don't necessarily > > agree with that. > > Agreed. I t

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Aug 4, 2015 at 1:15 PM, Alvaro Herrera wrote: > That opens up for lock escalation and deadlocks, doesn't it? You are > probably thinking that it's okay to ignore those but I don't necessarily > agree with that. Agreed. I think we're making a mountain out of a molehill here. As long as

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Wed, Aug 5, 2015 at 2:15 AM, Alvaro Herrera wrote: > Andres Freund wrote: >> On 2015-08-03 14:15:27 +0900, Michael Paquier wrote: > >> > As long as this only applies on master, this may be fine... We could >> > basically pass a LOCKMASK to the multiple layers of tablecmds.c >> > instead of LOCK

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

Andres Freund wrote: > On 2015-08-03 14:15:27 +0900, Michael Paquier wrote: > > As long as this only applies on master, this may be fine... We could > > basically pass a LOCKMASK to the multiple layers of tablecmds.c > > instead of LOCKMODE to track all the locks that need to be taken, and > > all

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Aug 4, 2015 at 5:55 AM, Andres Freund wrote: > > On 2015-08-03 14:15:27 +0900, Michael Paquier wrote: > > On Sat, Aug 1, 2015 at 9:20 PM, Andres Freund wrote: > > > On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote: > > >>> For instance, if you told me to choose between ShareLo

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On 2015-08-03 14:15:27 +0900, Michael Paquier wrote: > On Sat, Aug 1, 2015 at 9:20 PM, Andres Freund wrote: > > On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote: > >>> For instance, if you told me to choose between ShareLock and > >>> ShareUpdateExclusiveLock I wouldn't know which one

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Aug 4, 2015 at 9:12 AM, Fabrízio de Royes Mello wrote: > Are you sure we need to do all this changes just to check the highest > locklevel based on the reloptions? Well, by looking at the code that's what it looks as. That's a large change not that straight-forward. > Or I misunderstood

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Mon, Aug 3, 2015 at 2:15 AM, Michael Paquier wrote: > > On Sat, Aug 1, 2015 at 9:20 PM, Andres Freund wrote: > > On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote: > >>> For instance, if you told me to choose between ShareLock and > >>> ShareUpdateExclusiveLock I wouldn't know which

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Sat, Aug 1, 2015 at 9:20 PM, Andres Freund wrote: > On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote: >>> For instance, if you told me to choose between ShareLock and >>> ShareUpdateExclusiveLock I wouldn't know which one is strongest. I >>> don't it's sensible to have the "lock mo

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote: >On Sat, Aug 1, 2015 at 5:00 AM, Alvaro Herrera > wrote: >> Fabrízio de Royes Mello wrote: >> >>> In this patch I didn't change all lockmode comparison places >previous >>> pointed by you, but I can change it maybe adding other method

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Sat, Aug 1, 2015 at 5:00 AM, Alvaro Herrera wrote: > Fabrízio de Royes Mello wrote: > >> In this patch I didn't change all lockmode comparison places previous >> pointed by you, but I can change it maybe adding other method called >> LockModeIsValid(lockmode) to do the comparison "lockmode >= N

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

Fabrízio de Royes Mello wrote: > In this patch I didn't change all lockmode comparison places previous > pointed by you, but I can change it maybe adding other method called > LockModeIsValid(lockmode) to do the comparison "lockmode >= NoLock && > lockmode < MAX_LOCKMODES" used in many places. I

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Fri, Jul 31, 2015 at 10:01 AM, Michael Paquier wrote: > > On Fri, Jul 31, 2015 at 11:41 AM, Fabrízio de Royes Mello wrote: > >> We usually don't compare lock values that way, i.e. there's not > >> guaranteed to be a strict monotonicity between lock levels. I don't > >> really agree with that po

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Fri, Jul 31, 2015 at 10:05 PM, Simon Riggs wrote: > On 31 July 2015 at 02:46, Michael Paquier wrote: > >> >> > Added. I really don't know if my isolation tests are completely correct, >> > is >> > my first time writing this kind of tests. >> >> This patch size has increased from 16k to 157k be

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On 31 July 2015 at 02:46, Michael Paquier wrote: > > Added. I really don't know if my isolation tests are completely correct, > is > > my first time writing this kind of tests. > > This patch size has increased from 16k to 157k because of the output > of the isolation tests you just added. Tha

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Fri, Jul 31, 2015 at 12:21 PM, Fabrízio de Royes Mello wrote: > > On Thu, Jul 30, 2015 at 10:46 PM, Michael Paquier wrote: > > >> On further notice, I would recommend not to use the same string name >> for the session and the query identifiers. And I think that inserting >> only one tuple at in

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Fri, Jul 31, 2015 at 11:41 AM, Fabrízio de Royes Mello wrote: >> We usually don't compare lock values that way, i.e. there's not >> guaranteed to be a strict monotonicity between lock levels. I don't >> really agree with that policy, but it's nonetheless there. > > And how is the better way to c

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Thu, Jul 30, 2015 at 10:46 PM, Michael Paquier wrote: > > This patch size has increased from 16k to 157k because of the output > of the isolation tests you just added. This is definitely too large > and actually the test coverage is rather limited. Hence I think that > they should be changed as

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Fri, Jul 31, 2015 at 11:28 AM, Andres Freund wrote: > >> @@ -57,7 +57,8 @@ static relopt_bool boolRelOpts[] = > > If we go through this list, I'd rather make informed decisions about > each reloption. Otherwise we're going to get patches for each of them > separately over the next versions. Ju

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Thu, Jul 30, 2015 at 11:28 PM, Andres Freund wrote: > > > @@ -57,7 +57,8 @@ static relopt_bool boolRelOpts[] = > > If we go through this list, I'd rather make informed decisions about > each reloption. Otherwise we're going to get patches for each of them > separately over the next versions. >

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

> @@ -57,7 +57,8 @@ static relopt_bool boolRelOpts[] = If we go through this list, I'd rather make informed decisions about each reloption. Otherwise we're going to get patches for each of them separately over the next versions. > @@ -73,7 +75,8 @@ static relopt_bool boolRelOpts[] = >

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Fri, Jul 31, 2015 at 8:30 AM, Fabrízio de Royes Mello wrote: > > On Fri, Jul 24, 2015 at 4:05 AM, Michael Paquier > wrote: >> >> On Fri, Jul 24, 2015 at 7:11 AM, Fabrízio de Royes Mello >> wrote: >> > On Thu, Jul 2, 2015 at 2:03 PM, Simon Riggs >> > wrote: >> >> Looks functionally complete >

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Fri, Jul 24, 2015 at 7:11 AM, Fabrízio de Royes Mello wrote: > On Thu, Jul 2, 2015 at 2:03 PM, Simon Riggs wrote: >> Looks functionally complete >> >> Need a test to show that ALTER TABLE works on views, as discussed on this >> thread. And confirmation that pg_dump is not broken by this. >> >>

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Thu, Jul 2, 2015 at 2:03 PM, Simon Riggs wrote: > > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested > Documentation:not tested > > Looks func

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Looks functionally complete Need a test to show that ALTER TABLE works on vi

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Apr 7, 2015 at 10:57 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Tue, Apr 7, 2015 at 10:15 PM, Alvaro Herrera wrote: > > > > Fabrízio de Royes Mello wrote: > > > On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera < alvhe...@2ndquadrant.com> > > > wrote: > > > > > >

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Apr 7, 2015 at 10:15 PM, Alvaro Herrera wrote: > > Fabrízio de Royes Mello wrote: > > On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera < alvhe...@2ndquadrant.com> > > wrote: > > > > > > Fabrízio de Royes Mello wrote: > > > > > > > Ok guys. The attached patch refactor the reloptions adding a

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

Fabrízio de Royes Mello wrote: > On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera > wrote: > > > > Fabrízio de Royes Mello wrote: > > > > > Ok guys. The attached patch refactor the reloptions adding a new field > > > "lockmode" in "relopt_gen" struct and a new method to determine the > > > required

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera wrote: > > Fabrízio de Royes Mello wrote: > > > Ok guys. The attached patch refactor the reloptions adding a new field > > "lockmode" in "relopt_gen" struct and a new method to determine the > > required lock level from an option list. > > > > We nee

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

Fabrízio de Royes Mello wrote: > Ok guys. The attached patch refactor the reloptions adding a new field > "lockmode" in "relopt_gen" struct and a new method to determine the > required lock level from an option list. > > We need determine the appropriate lock level for each reloption: I don't th

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Wed, Apr 1, 2015 at 1:45 AM, Noah Misch wrote: > > On Tue, Mar 31, 2015 at 01:17:03PM -0400, Robert Haas wrote: > > On Tue, Mar 31, 2015 at 9:11 AM, Fabrízio de Royes Mello > > wrote: > > > Attached a very WIP patch to reduce lock level when setting autovacuum > > > reloptions in "ALTER TABLE

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Mar 31, 2015 at 01:17:03PM -0400, Robert Haas wrote: > On Tue, Mar 31, 2015 at 9:11 AM, Fabrízio de Royes Mello > wrote: > > Attached a very WIP patch to reduce lock level when setting autovacuum > > reloptions in "ALTER TABLE .. SET ( .. )" statement. > > I think the first thing we need

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Mar 31, 2015 at 9:11 AM, Fabrízio de Royes Mello wrote: > Attached a very WIP patch to reduce lock level when setting autovacuum > reloptions in "ALTER TABLE .. SET ( .. )" statement. I think the first thing we need to here is analyze all of the options and determine what the appropriate

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Mon, Mar 30, 2015 at 8:14 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > > On Mon, Mar 30, 2015 at 7:41 PM, Jim Nasby wrote: > > > > On 3/27/15 2:23 PM, Fabrízio de Royes Mello wrote: > >> > >> Hi all, > >> > >> I'm tweaking some autovacuum settings in a table with high wri

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Mon, Mar 30, 2015 at 7:41 PM, Jim Nasby wrote: > > On 3/27/15 2:23 PM, Fabrízio de Royes Mello wrote: >> >> Hi all, >> >> I'm tweaking some autovacuum settings in a table with high write usage >> but with ALTER TABLE .. SET ( .. ) this task was impossible, so I did a >> catalog update (pg_clas

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On 3/27/15 2:23 PM, Fabrízio de Royes Mello wrote: Hi all, I'm tweaking some autovacuum settings in a table with high write usage but with ALTER TABLE .. SET ( .. ) this task was impossible, so I did a catalog update (pg_class) to change reloptions. Maybe it's a stupid doubt, but why we need t

Re: [HACKERS] Doubt about boundParams

On Tue, Aug 2, 2011 at 3:45 PM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote: > On 02.08.2011 12:54, Ashutosh Bapat wrote: > >> Hi All, >> I am looking at usage of bound parameters. >> >> In functions SPI_cursor_open_with_args() and SPI_cursor_open_with_args() >> parameters are

Re: [HACKERS] Doubt about boundParams

On 02.08.2011 12:54, Ashutosh Bapat wrote: Hi All, I am looking at usage of bound parameters. In functions SPI_cursor_open_with_args() and SPI_cursor_open_with_args() parameters are flagged as constants and passed to the planner in following manner, paramLI = _SPI_convert_params(nargs, argtypes,

Re: [HACKERS] Doubt

On May 25, 2009, at 9:41 AM, jibin jose wrote: which tool is used as profiler in postgresql There is some code in the backend to support gprof; I know that some people have had good luck with oprofile, too, which doesn't require any special support. ...Robert -- Sent via pgsql-hackers

Re: [HACKERS] Doubt in index subplan query

On Jun 20, 2008, at 1:11 AM, Suresh wrote: I have a query plan for a certain query Nested Loop (cost=1.00..38761761090.50 rows=3000608 width=8) -> Seq Scan on lineitem (cost=1.00..100213649.15 rows=6001215 width=8) -> Index Scan using oindex2 on myorders (cost=0.00.

Re: [HACKERS] Doubt in index scan code

On 8-Mar-08, at 11:06 AM, Suresh wrote: Hello all, I have a custom code written inside postgres in an application we use. The snippet is as below : Here inner plan is an index scan. scandesc = ((IndexScanState *)innerPlan)->iss_ScanDesc; flag=index_getmulti(scandesc, &tidelm->tid, 1, &re

Re: [HACKERS] Doubt in heap_release_fetch

Suresh <[EMAIL PROTECTED]> writes: > What is the time qualification check ? HeapTupleSatisfiesVisibility(). See src/include/utils/tqual.h src/backend/utils/time/tqual.c and if none of this is making any sense maybe you need to start here: http://developer.postgresql.org/pgdocs/postgres/mvcc.html

Re: [HACKERS] Doubt in IndexScanDescData

One thing you might be missing is that indexes are relations too. They're a bit different than heap relations (ie "tables") but they share enough structure that it's worth using the same datatypes to represent both. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me

Re: [HACKERS] Doubt in IndexScanDescData

take a look at that ... http://www.postgresql.org/docs/8.3/static/indexam.html this might clear up the problem. here is an example making clear what happens: select phone_number from phonebook where name = 'xy'; index is asked to find the right place in the heap to retrieve the data. t

Re: [HACKERS] Doubt in IndexScanDescData

Hans-Juergen Schoenig <[EMAIL PROTECTED]> wrote: On Feb 17, 2008, at 4:33 PM, Suresh wrote: [ "include/access/relscan.h" ] In IndexScanDescData, whats the purpose of having two Relation variables. typedef struct IndexScanDescData { RelationheapRelation; /* heap relation des

Re: [HACKERS] Doubt in IndexScanDescData

On Feb 17, 2008, at 4:33 PM, Suresh wrote: [ "include/access/relscan.h" ] In IndexScanDescData, whats the purpose of having two Relation variables. typedef struct IndexScanDescData { RelationheapRelation; /* heap relation descriptor, or NULL */ Relation

Re: [HACKERS] doubt

Ühel kenal päeval, N, 2007-07-12 kell 14:00, kirjutas Hannu Krosing: > Ühel kenal päeval, K, 2007-07-11 kell 19:08, kirjutas Greg Smith: > > On Wed, 11 Jul 2007, Narasimha Rao P.A wrote: > > > > > Does postgreSQL support distributive query processing > > > > Not internally. It's possible in some

Re: [HACKERS] doubt

Ühel kenal päeval, K, 2007-07-11 kell 19:08, kirjutas Greg Smith: > On Wed, 11 Jul 2007, Narasimha Rao P.A wrote: > > > Does postgreSQL support distributive query processing > > Not internally. It's possible in some situations to split queries up > across multiple nodes using add-on software.

Re: [HACKERS] doubt

On Wed, 11 Jul 2007, Narasimha Rao P.A wrote: Does postgreSQL support distributive query processing Not internally. It's possible in some situations to split queries up across multiple nodes using add-on software. pgpool-II, available at http://pgfoundry.org/projects/pgpool/ provides an im

Re: [HACKERS] doubt

Narasimha Rao P.A wrote: Does postgreSQL support distributive query processing No. Get the freedom to save as many mails as you wish. Click here to know how. -- === The

Re: [HACKERS] Doubt in parser

Michael Glaesemann <[EMAIL PROTECTED]> writes: > On Feb 16, 2006, at 21:37 , Dhanaraj wrote: >> currently i looking at the postgres src code. I saw the scanner and >> parser implemetations at two different places (src/backend/parser/ >> and /src/bakend/bootstrp). Can anybody tell me the purpo

Re: [HACKERS] Doubt in parser

On Feb 16, 2006, at 21:37 , Dhanaraj wrote: hi currently i looking at the postgres src code. I saw the scanner and parser implemetations at two different places (src/backend/parser/ and /src/bakend/bootstrp). Can anybody tell me the purpose of having two phases?? or will this help to p

Re: [HACKERS] Doubt in parser

Dhanaraj wrote: > hi > > currently i looking at the postgres src code. I saw the scanner and > parser implemetations at two different places (src/backend/parser/ and > /src/bakend/bootstrp). Can anybody tell me the purpose of having two > phases?? or will this help to parse the queries at dif

Re: [HACKERS] Doubt in parser

On Thu, Feb 16, 2006 at 06:07:25PM +0530, Dhanaraj wrote: > hi > > currently i looking at the postgres src code. I saw the scanner and > parser implemetations at two different places (src/backend/parser/ and > /src/bakend/bootstrp). Can anybody tell me the purpose of having two > phases?? or

Re: [HACKERS] Doubt

On Fri, 2005-11-25 at 15:24 -0300, Gustavo Tonini wrote: > What is "ISTM"? Google tells me it stands for The Irish Society for Travel Medicine, but it also gives a few other suggestions. ISTM that google has the answer. :-) Best Regards, Simon Riggs ---(end of broadcast

Re: [HACKERS] Doubt

It Seems To Me.   Here’s a decent list of common acronyms:   http://www.fun-with-words.com/acronyms.html   Mike Pollard SUPRA Server SQL Engineering and Support Cincom Systems, Inc.  Better to remain silent and be thought a fool than to speak out

Re: [HACKERS] Doubt w.r.t vacuum

On 28 Jul 2003 at 9:56, Alvaro Herrera wrote: > On Mon, Jul 28, 2003 at 02:29:36PM +0530, Shridhar Daithankar wrote: > > > I was just wondering over it. This is for difference between vacuum full and > > vacuum analyze. Can somebody enlighten, > > Actually, the different concepts are "lazy vacu

Re: [HACKERS] Doubt w.r.t vacuum

On Mon, 2003-07-28 at 11:04, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Vacuum full locks the entire table and moves tuples between pages. It > > leaves all pages full of tuples (except, obviously, the last one), so it > > doesn't need to record them in the FSM. > > This is

Re: [HACKERS] Doubt w.r.t vacuum

Robert Treat <[EMAIL PROTECTED]> writes: >> This is overoptimistic :-(. VACUUM FULL cannot necessarily compact the >> table completely, and so it will record free space in FSM (if there is >> any worth recording). An example situation is that page 1000 may >> contain a very large tuple, which wil

Re: [HACKERS] Doubt w.r.t vacuum

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Vacuum full locks the entire table and moves tuples between pages. It > leaves all pages full of tuples (except, obviously, the last one), so it > doesn't need to record them in the FSM. This is overoptimistic :-(. VACUUM FULL cannot necessarily compa

Re: [HACKERS] Doubt w.r.t vacuum

"Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > 1. IIRC vacuum recovers/reuses dead tuples generated from update but can not do > so for delete? Why? This is not correct. > 2. Vacuum full locks entire table, is it possible that it locks a page at a > time and deal with it. No. You can't c

Re: [HACKERS] Doubt w.r.t vacuum

On Mon, Jul 28, 2003 at 02:29:36PM +0530, Shridhar Daithankar wrote: > I was just wondering over it. This is for difference between vacuum full and > vacuum analyze. Can somebody enlighten, Actually, the different concepts are "lazy vacuum" (plain VACUUM command, with or without ANALYZE) and ful

Re: [HACKERS] Doubt w.r.t vacuum

On 28 Jul 2003 at 9:11, Doug McNaught wrote: > "Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I was just wondering over it. This is for difference between vacuum full and > > vacuum analyze. Can somebody enlighten, > > > > 1. IIRC vacuum recovers/reuses dead tuples generat

Re: [HACKERS] Doubt w.r.t vacuum

"Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > Hi, > > I was just wondering over it. This is for difference between vacuum full and > vacuum analyze. Can somebody enlighten, > > 1. IIRC vacuum recovers/reuses dead tuples generated from update but can not do > so for delete? Why? YDNRC.