Peter Eisentraut wrote:
> So assuming we allowed units in postgresql.conf, how would you report
> them with SHOW?
>
> 1. The way they were set (hard)
>
> 2. Without units (not user-friendly)
>
> 3. Always in base units (seconds or bytes)
>
> 4. The largest unit that gives an integer
>
> (4) s
I think we do know, have you reviewed the results in the briefing?
- Luke
Sent from my GoodLink synchronized handheld (www.good.com)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 25, 2006 01:09 AM Eastern Standard Time
To: Tom Lane
Cc
On Tue, Jul 25, 2006 at 12:36:42AM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > Reading 1/4, for a larger table, has a good chance of being faster than
> > reading 4/4 of the table. :-)
> Really?
>
> If you have to hit one tuple out of four, it's pretty much guaranteed
> that you will ne
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, how about CREATE INDEX x NOLOCK ON tab ... Please don't use it as
> the first word. I am afraid we would regret that.
> Or maybe CREATE INDEX x ON tab NOLOCK Having the NOLOCK
> associated with the table name makes sense.
psql would be a lot h
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> Oh, psql needs to know before the command is sent? How do we handle it
> >> now with CLUSTER?
>
> > We don't, which is exactly the problem. If I'm not mistaken, currently
> > psql in autocommit off mode, C
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Do we add pgstatindex as a new contrib module,
> or merge it into contrib/pgstattuple?
I believe Alvaro was suggesting that you should add it as an additional
SQL function within contrib/pgstattuple. That'd be my advice too ---
I don't see a reason t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Oh, psql needs to know before the command is sent? How do we handle it
>> now with CLUSTER?
> We don't, which is exactly the problem. If I'm not mistaken, currently
> psql in autocommit off mode, CLUSTER doesn't start a transac
[EMAIL PROTECTED] writes:
> Reading 1/4, for a larger table, has a good chance of being faster than
> reading 4/4 of the table. :-)
Really?
If you have to hit one tuple out of four, it's pretty much guaranteed
that you will need to fetch every heap page. So using an index provides
zero I/O savin
Chris Browne <[EMAIL PROTECTED]> writes:
> In support of PG 8.2, we need to have the log trigger function do the
> following:
> - Save value of standards_conforming_string
> - Set value of standards_conforming_string to FALSE
This is a good idea why exactly? What are you even expecting it to
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is it intentional that effective_cache_size is a real (as opposed to
> integer)?
Yes --- the planner generally does all that stuff in float arithmetic to
avoid worrying about overflow.
regards, tom lane
-
Jie Zhang wrote:
On 7/24/06 6:59 AM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
And also for AND-s of several indexes, where indexes are BIG, your btree
indexes may be almost as big as tables but the resulting set of pages is
small.
Yeah, Hannu points it out very well -- the bitmap index w
Bruce Momjian wrote:
> > Anyway, if you want psql to easily identify it, just return NOLOCK as
> > part of the command string returned:
> >
> > test=> create index i on test(x);
> > CREATE INDEX NOLOCK
>
> Oh, psql needs to know before the command is sent? How do we handle it
> now with
Marc Munro wrote:
-- Start of PGP signed section.
> On Mon, 2006-07-24 at 15:17 -0400, Tom Lane wrote:
> > No, being able to do that is exactly the point of the custom-GUC
> > mechanism.
>
> Excellent. I shall study this and hope to bother you no further :-)
>
And in 8.2, postgresql.conf can in
Bruce Momjian wrote:
> Rod Taylor wrote:
> > Sorry, hit send too quickly.
> >
> > NOLOCK is kinda like NOWAIT, except implies that the command will not
> > take a strong lock instead of stating that it will not wait for one.
> >
> > On Mon, 2006-07-24 at 11:20 -0400, Rod Taylor wrote:
> > > >
Rod Taylor wrote:
> Sorry, hit send too quickly.
>
> NOLOCK is kinda like NOWAIT, except implies that the command will not
> take a strong lock instead of stating that it will not wait for one.
>
> On Mon, 2006-07-24 at 11:20 -0400, Rod Taylor wrote:
> > > SHARED CREATE INDEX
I like NOLOC
Tom Lane wrote:
> "Albe Laurenz" <[EMAIL PROTECTED]> writes:
> > Any chance that my LDAP patch
> > http://momjian.us/mhonarc/patches/msg0.html
> > will get reviewed before the feature freeze?
>
> Feature freeze is the deadline for patch submission, not patch application.
Right, and it will be
On Mon, Jul 24, 2006 at 09:04:28PM -0400, Bruce Momjian wrote:
> Jie Zhang wrote:
> > > IIRC they quoted the cardinality of 1 as something that is still
> > > faster than btree for several usecases.
> > >
> > > And also for AND-s of several indexes, where indexes are BIG, your btree
> > > inde
On Mon, 24 Jul 2006, Bruce Momjian wrote:
> Jie Zhang wrote:
> > > IIRC they quoted the cardinality of 1 as something that is still
> > > faster than btree for several usecases.
> > >
> > > And also for AND-s of several indexes, where indexes are BIG, your btree
> > > indexes may be almost as
On 7/24/06 6:04 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Jie Zhang wrote:
>>> IIRC they quoted the cardinality of 1 as something that is still
>>> faster than btree for several usecases.
>>>
>>> And also for AND-s of several indexes, where indexes are BIG, your btree
>>> indexes may
Tatsuo Ishii wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Mario Weilguni wrote:
> > > > > Will this patch make it into 8.2?
> > > > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php
> > > > >
> > > > > It's a really nice feature, would be extremly useful wi
On Mon, Jul 24, 2006 at 11:13:53PM +0200, Peter Eisentraut wrote:
> So assuming we allowed units in postgresql.conf, how would you report
> them with SHOW?
>
> 1. The way they were set (hard)
>
> 2. Without units (not user-friendly)
>
> 3. Always in base units (seconds or bytes)
>
> 4. The lar
Jie Zhang wrote:
> > IIRC they quoted the cardinality of 1 as something that is still
> > faster than btree for several usecases.
> >
> > And also for AND-s of several indexes, where indexes are BIG, your btree
> > indexes may be almost as big as tables but the resulting set of pages is
> > sm
You should submit to -patches; at least that it should either get
into the queue or you should get a reason why it didn't.
On Jul 17, 2006, at 4:27 PM, Martin Pitt wrote:
some time ago I started a discussion [1] here about modifying pg_dump
to not restore TABLE DATA objects if the correspondin
On 7/24/06 6:59 AM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
> Ühel kenal päeval, P, 2006-07-23 kell 20:25, kirjutas Tom Lane:
>> Gavin Sherry <[EMAIL PROTECTED]> writes:
>>> On Sun, 23 Jul 2006, Tom Lane wrote:
However, the main problem I've got with this is that a new index AM is a
On Jul 16, 2006, at 3:08 PM, Andrew Dunstan wrote:
Kris Jurka wrote:
For my cygwin buildfarm member I setup cron, but the make step
failed for every build for unknown reasons while succeeding if not
run from cron.
Is this still happening? We should try to get to the bottom of it.
Try s
Tom Lane wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > This is a revised patch originated by Junji TERAMOTO for HEAD.
> > [BTree vacuum before page splitting]
> > http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
> > I think we can resurrect his idea because we will
Peter Eisentraut wrote:
Joshua D. Drake wrote:
What do you want to hear? I have my emails in correspondence asking
for the relicense and the approval to submit.
Is there something specific you are looking for?
Either the author is going to abandon development, then it might make
sense to pic
Chris Browne wrote:
> In support of PG 8.2, we need to have the log trigger function do the
> following:
> - Save value of standards_conforming_string
> - Set value of standards_conforming_string to FALSE
> - proceed with saving data to sl_log_?
> - Recover value of standards_conforming_str
In support of PG 8.2, we need to have the log trigger function do the
following:
- Save value of standards_conforming_string
- Set value of standards_conforming_string to FALSE
- proceed with saving data to sl_log_?
- Recover value of standards_conforming_string
The variable, standards_co
Peter,
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.
I beleive that it's a real because the oth
Joe Conway wrote:
(cross-posted from PATCHES without the attachement)
I just received this (offlist), and have not had a chance to review it
myself yet, but figured I should post it now in case others want to have
a look and comment or discuss before feature freeze.
Is there a downside to this
FYI, I have been offline for the past few days because of storm damage
in my area. Things have been repaired and my server is back online.
Also, my trip to the UK, India, and Pakistan that I announced at our
10th anniversary has been postponed until September.
--
Bruce Momjian [EMAIL PROTEC
On Mon, 2006-07-24 at 22:55 +0200, Peter Eisentraut wrote:
> Is it intentional that effective_cache_size is a real (as opposed to
> integer)? The initial revision of guc.c already has it that way, so it
> was probably blindly adapted from the previous adhockery that had all
> planner variables
Jim Nasby wrote:
> If memory serves, we also wanted to have the postmaster log a warning
> if it reloaded postgresql.conf and found values that had changed but
> wouldn't take effect until restart.
It already does that.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
--
So assuming we allowed units in postgresql.conf, how would you report
them with SHOW?
1. The way they were set (hard)
2. Without units (not user-friendly)
3. Always in base units (seconds or bytes)
4. The largest unit that gives an integer
(4) seems the most reasonable to me in terms of inter
Peter Eisentraut wrote:
> Greg Stark wrote:
> > One thing to think about, what will the command to execute stored
> > procedures look like? Those will also need to be called from outside
> > a transaction.
>
> Huh? Only if you invent your own stored-procedure theory or have a
> hitherto unknown
On Jul 17, 2006, at 2:48 PM, Zdenek Kotala wrote:
Josh Berkus wrote:
Zdenek,
I would like to implement "Mark change-on-restart-only values in
postgresql.conf" item. Anybody works on this? Does it mean add extra
comment to postgresql.conf for variable which has PG_POSTMASTER
context?
Somehow
Excellent! I'll submit a doc patch shortly.
Regards,
-Robert
Peter Eisentraut wrote:
I've committed the dtrace patch. Some documentation would be nice now ...
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.
--
Peter Eisentraut
http://developer.postgresql.org/~
Greg Stark wrote:
> One thing to think about, what will the command to execute stored
> procedures look like? Those will also need to be called from outside
> a transaction.
Huh? Only if you invent your own stored-procedure theory or have a
hitherto unknown interpretation of the SQL standard.
-
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I'm also wondering about where in the command the keyword should go.
> > As submitted it's
> >
> > [ WITH ( > class="PARAMETER">storage_parameter = > class="PARAMETER">value [, ... ] ) ]
> > [ TABLESPACE tablespace ]
>
On Mon, 24 Jul 2006, Tom Lane wrote:
Personally I don't think retail vacuuming in that form will ever fly
anyway, so I have no problem with installing the proposed patch,
but I thought I'd better throw this comment out to see if anyone
thinks it's a big deal.
My feeling is that retail vacuumin
Greg Stark asked:
> I know Oracle calls this "online" index builds. In fact it
> works similarly
> with a single keyword "online" tacked on near the end of the
> create index
> statement.
>
> Anyone know what MSSQL or DB2 call it?
>
I have to live with MSSQL at work, and I didn't remember an
On Mon, 2006-07-24 at 15:17 -0400, Tom Lane wrote:
> No, being able to do that is exactly the point of the custom-GUC
> mechanism.
Excellent. I shall study this and hope to bother you no further :-)
Thanks.
__
Marc
signature.asc
Description: This is a digitally signed message part
Marc Munro <[EMAIL PROTECTED]> writes:
> I don't think it's already solved but I may be missing the point. The
> Veil shared library will be loaded by process_preload_libraries only
> after the postgresql config file has been read. I was assuming that at
> this point it would be too late to speci
On Mon, 2006-07-24 at 14:44 -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Marc Munro wrote:
> >> I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
> >> configuration details from a configuration file.
>
> > What kind of details? By the time any serve
On Mon, 2006-07-24 at 20:31 +0200, Peter Eisentraut wrote:
> Marc Munro wrote:
> > I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
> > configuration details from a configuration file.
>
> What kind of details? By the time any server-side module is loaded, the
> configuration
Tom Lane <[EMAIL PROTECTED]> writes:
> I'm fairly dissatisfied with the naming of Greg Stark's proposed new
> feature for creating indexes without blocking writers of the table.
> To my mind, "ONLINE" just doesn't convey any useful information ---
> the existing CREATE INDEX functionality could al
Peter Eisentraut wrote:
Marc Munro wrote:
I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
configuration details from a configuration file.
What kind of details? By the time any server-side module is loaded, the
configuration file has already been read, so why wou
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Marc Munro wrote:
>> I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
>> configuration details from a configuration file.
> What kind of details? By the time any server-side module is loaded, the
> configuration file has already
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A possible objection to this is that it would foreclose running VACUUM
>> and ANALYZE as a single transaction, exactly because of the point that
>> we couldn't insert pg_statistic rows using a lazy vacuum's XID.
> Hmm, what about havi
Marc Munro wrote:
> I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
> configuration details from a configuration file.
What kind of details? By the time any server-side module is loaded, the
configuration file has already been read, so why would you need to read
it again?
(cross-posted from PATCHES without the attachement)
I just received this (offlist), and have not had a chance to review it
myself yet, but figured I should post it now in case others want to have
a look and comment or discuss before feature freeze.
If there are no major objections to the concept
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hannu Krossing asked me about his patch to ignore transactions running
> > VACUUM LAZY in other vacuum transactions. I attach a version of the
> > patch updated to the current sources.
>
> nonInVacuumXmin seems useless ... perhaps a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hannu Krossing asked me about his patch to ignore transactions running
> VACUUM LAZY in other vacuum transactions. I attach a version of the
> patch updated to the current sources.
nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
ver
Nicolai Petri wrote:
> If people hate contrib so much why not just get rid of it forever.. Either it
> should embrace as much small contrib modules as possible - else it should
> disappear in my opinion.
Actually that's partly the intention. Several contrib modules have been
removed in the rec
Joachim Wieland wrote:
> On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
> > Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> > > #2: That variable can *not* be changed by a reload.
> > > Notice-level message is sent to the log notifying the admin
> > > that the change
Joshua D. Drake wrote:
> What do you want to hear? I have my emails in correspondence asking
> for the relicense and the approval to submit.
>
> Is there something specific you are looking for?
Either the author is going to abandon development, then it might make
sense to pick up the pieces withi
Sorry that nobody caught it (including myself), but good lord it isn't
that big of a deal.
Consistency is important. It may not be _THAT_ big a deal, but we
should be at least a little careful.
I do not disagree. All I was saying was that it is a very common mistake
(see secondary note sa
On Mon, Jul 24, 2006 at 10:55:47AM -0400, Stephen Frost wrote:
> #2: That variable can *not* be changed by a reload.
> Notice-level message is sent to the log notifying the admin that the
> change requested could not be performed. This change could be
> either a revert to reset-val
Joshua D. Drake wrote:
> Peter Eisentraut wrote:
> >Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera:
> >>Side question -- is it plRuby or PL/Ruby? We should be consistent. I
> >>just noticed the top-level README file has all the wrong names -- what
> >>is "pl/c" for starters? Or plPgsql?
I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
configuration details from a configuration file. Rather than implement
my own config file parser, I'd like to be able to re-use the parser
defined in guc-file.l
If this is not contentious, I will submit a patch to make the parse
Peter Eisentraut wrote:
Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera:
Side question -- is it plRuby or PL/Ruby? We should be consistent. I
just noticed the top-level README file has all the wrong names -- what
is "pl/c" for starters? Or plPgsql? We've _never_ used those names.
I'm
On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
> Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> > #2: That variable can *not* be changed by a reload.
> > Notice-level message is sent to the log notifying the admin that the
> > change requested could not be perfor
Peter Eisentraut wrote:
Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera:
Side question -- is it plRuby or PL/Ruby? We should be consistent. I
just noticed the top-level README file has all the wrong names -- what
is "pl/c" for starters? Or plPgsql? We've _never_ used those names.
I'm
Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> #2: That variable can *not* be changed by a reload.
> Notice-level message is sent to the log notifying the admin that the
> change requested could not be performed.
This already happens.
--
Peter Eisentraut
http://developer.postg
Peter Eisentraut wrote:
Am Montag, 24. Juli 2006 18:23 schrieb Joshua D. Drake:
O.k. so we don't loose this. Do we want to work on PL/Ruby in core or not?
Unless you plan to fork or hijack the package, we need to hear from the author
first.
What do you want to hear? I have my emails in corr
Hello all
I'm in the need for my custom written replication engine to obtain the current
transaction id from a trigger function. As far as I'm told it's not possible
today. Would people object much if this functionality was added for 8.2 ?
It's the last piece of postgresql C code I have left in
On Wednesday 03 May 2006 19:49, Jim C. Nasby wrote:
> On Wed, May 03, 2006 at 07:06:09PM +0200, hubert depesz lubaczewski wrote:
> > hi
> > some time ago i was told on postgresql-general about existence of
> > "hstore" package for postgresql.
> > as i understand it is being developed by the same gu
Bort, Paul wrote:
Given the concerns about running this on machines that don't have a lot
of CPU and disk to spare, should it ship disabled?
Yes, certainly.
Andrew, what do you think of pgbench reports shipping separately? I have
no idea how the server end is set up, so I don't know how mu
Am Montag, 24. Juli 2006 18:49 schrieb Alvaro Herrera:
> Side question -- is it plRuby or PL/Ruby? We should be consistent. I
> just noticed the top-level README file has all the wrong names -- what
> is "pl/c" for starters? Or plPgsql? We've _never_ used those names.
I'm beginning to think th
Joshua D. Drake wrote:
> Josh Berkus wrote:
> >Neil,
> >
> >>(FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some
> >>prior experience with Ruby and its C API.)
> >
> >Well, if you're willing to be a maintainer, that removes a major roadblock.
> >
>
> O.k. so we don't loose this. Do
Andrew Dunstan wrote:
>
> We are really not going to go in this direction. If you want ideal
> performance tests then a heterogenous distributed collection of
> autonomous systems like buildfarm is not what you want.
>
> You are going to have to live with the fatc that there will be
> occasio
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> This is a revised patch originated by Junji TERAMOTO for HEAD.
> [BTree vacuum before page splitting]
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
> I think we can resurrect his idea because we will scan btree pages
> at-atim
Am Montag, 24. Juli 2006 18:23 schrieb Joshua D. Drake:
> O.k. so we don't loose this. Do we want to work on PL/Ruby in core or not?
Unless you plan to fork or hijack the package, we need to hear from the author
first.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
--
I've committed the dtrace patch. Some documentation would be nice now ...
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: explain analyze is your friend
Josh Berkus wrote:
Neil,
(FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some
prior experience with Ruby and its C API.)
Well, if you're willing to be a maintainer, that removes a major roadblock.
O.k. so we don't loose this. Do we want to work on PL/Ruby in core or not?
Jo
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
How could there be a concurrent update of the _same_ row, when
I do "select * from bar *for update*".
AFAICT the spec doesn't require one to have written FOR UPDATE
in order to use WHERE CURRENT OF. (In effect, they expect FOR UPD
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 24. Juli 2006 17:13 schrieb Tom Lane:
>> I'm tempted to put the new keyword at the very front:
>>
>> SHARED CREATE INDEX
>>
>> which would probably mean that we'd have to document it as if it were a
>> completely separate command from
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> How could there be a concurrent update of the _same_ row, when
> I do "select * from bar *for update*".
AFAICT the spec doesn't require one to have written FOR UPDATE
in order to use WHERE CURRENT OF. (In effect, they expect FOR UPDATE
to be the de
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> No, a concurrent vacuum can't change that because vacuum can't change
> the page unless it can get a super-exclusive lock on it (which means
> nobody else can have a scan stopped at that page, which is exactly
> what this cursor has).
More to the point,
Am Montag, 24. Juli 2006 17:13 schrieb Tom Lane:
> To my mind, "ONLINE" just doesn't convey any useful information ---
> the existing CREATE INDEX functionality could already be said to be
> "online", in the sense that you don't have to take down the database
> to do it. I thought about "SHARED" b
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Couldn't this be emulated by doing
begin;
declare foo cursor for select * from bar for update;
fetch foo into v_foo ;
update bar set abc='def' where ctid = v_foo.ctid;
That wouldn't follow the expected semantics if there's a concur
Florian G. Pflug wrote:
> Gavin Sherry wrote:
> >On Mon, 24 Jul 2006, Golden Liu wrote:
> >
> >>begin;
> >>declare foo cursor for select * from bar for update;
> >>fetch foo;
> >>update bar set abc='def' where current of foo;
> >>fetch foo;
> >>delete from bar where current of foo;
> >>commit;
>
>
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Couldn't this be emulated by doing
> begin;
> declare foo cursor for select * from bar for update;
> fetch foo into v_foo ;
> update bar set abc='def' where ctid = v_foo.ctid;
That wouldn't follow the expected semantics if there's a concurrent
updat
Sorry, hit send too quickly.
NOLOCK is kinda like NOWAIT, except implies that the command will not
take a strong lock instead of stating that it will not wait for one.
On Mon, 2006-07-24 at 11:20 -0400, Rod Taylor wrote:
> > SHARED CREATE INDEX
>
> > Comments?
>
> CREATE [UNIQUE] INDEX
> SHARED CREATE INDEX
> Comments?
CREATE [UNIQUE] INDEX [WITH NOLOCK] ON ...
--
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
I'm fairly dissatisfied with the naming of Greg Stark's proposed new
feature for creating indexes without blocking writers of the table.
To my mind, "ONLINE" just doesn't convey any useful information ---
the existing CREATE INDEX functionality could already be said to be
"online", in the sense tha
Gavin Sherry wrote:
On Mon, 24 Jul 2006, Golden Liu wrote:
begin;
declare foo cursor for select * from bar for update;
fetch foo;
update bar set abc='def' where current of foo;
fetch foo;
delete from bar where current of foo;
commit;
No one has stepped up to do this for 8.2 so unfortunately
On Mon, 24 Jul 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
Since the feature freeze is in a few days, I'm sending the first iteration
of my patch implementing the multi-argument aggregates (PolyArgAgg) (SOC
project)
This patch is nowhere near ready for submission :-(
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> > I did not check the changes you have done to set_config_option and the like
> > but tested the commenting / uncommenting / changing of guc variables and the
> > behavior and log output. The general idea (at leas
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Since the feature freeze is in a few days, I'm sending the first iteration
> of my patch implementing the multi-argument aggregates (PolyArgAgg) (SOC
> project)
This patch is nowhere near ready for submission :-(. Most of the
comments seem to be
Joachim Wieland <[EMAIL PROTECTED]> writes:
> I did not check the changes you have done to set_config_option and the like
> but tested the commenting / uncommenting / changing of guc variables and the
> behavior and log output. The general idea (at least my idea) is that
> whenever a SIGHUP is rece
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Any chance that my LDAP patch
> http://momjian.us/mhonarc/patches/msg0.html
> will get reviewed before the feature freeze?
Feature freeze is the deadline for patch submission, not patch application.
regards, tom lane
--
Ühel kenal päeval, P, 2006-07-23 kell 20:25, kirjutas Tom Lane:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Sun, 23 Jul 2006, Tom Lane wrote:
> >> However, the main problem I've got with this is that a new index AM is a
> >> pretty large burden, and no one's made the slightest effort to sell
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
Scale factor 10 produces an accounts table of about 130 Mb. Given that
most HW these days has at least 1G of ram, this probably means not much
retrieval IO is tested (only checkpoint and wal fsync). Do we want to
try 100 or even 200?
Is there a way to figure out from the catalogs somehow the largest size in
bytes of the largest tuple in a relation without going one by one over the
relation and calculating that. alternatively, without actually pulling out
the whole tuple from the disk?
(It is necessary for the algorithm to kn
Gavin Sherry wrote:
Not all machines stay the same over time.
A machine may by upgraded, a machine may be getting backed up or may in
some other way be utilised during a performance test. This would skew the
stats for that machine. It may confuse people more than help them...
At the very least,
Dave Page wrote:
With help from Andrew Dunstan, I'm adding the ability to do a pgbench
run after all of the other tests during a buildfarm run.
Please ensure the run is optional. The machine hosting Snake and
Bandicoot is currently running 16 builds a day, and I'd prefer not to
signif
Hi,
On Monday 24 July 2006 11:26, Csaba Nagy wrote:
> [snip]
>
> > OTOH, one has to be very careful to not mix terms here. In industrial
> > (production floor) applications, the term 'real time database' refers to
> > soemthing completely different than a relational, transactional DB.
>
> But "rel
1 - 100 of 108 matches
Mail list logo
