On Fri, 2006-03-17 at 13:29 +0800, Qingqing Zhou wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote
> >
> Interesting, I understand that shared_work_mem is process-wise,
> allocate-when-use, request-may-or-may-not-get-it (as you have pointed out,
> this may make planner in a hard situation if we are
What sense is this supposed to make?
=> begin;
BEGIN
=> blah;
ERROR: ...
=> commit;
ROLLBACK
Even if this is justifiable, this behavior is not documented (in any obvious
place).
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
Ühel kenal päeval, R, 2006-03-17 kell 10:12, kirjutas Peter Eisentraut:
> What sense is this supposed to make?
>
> => begin;
> BEGIN
> => blah;
> ERROR: ...
> => commit;
> ROLLBACK
>
Return status tells you what actually happened.
> Even if this is justifiable, this behavior is not docu
Am Freitag, 17. März 2006 11:25 schrieb Hannu Krosing:
> > => commit;
> > ROLLBACK
> >
>
> Return status tells you what actually happened.
If I send a COMMIT, I want a commit to happen or an error.
> > Even if this is justifiable, this behavior is not documented (in any
> > obvious place
Ühel kenal päeval, R, 2006-03-17 kell 11:27, kirjutas Peter Eisentraut:
> Am Freitag, 17. März 2006 11:25 schrieb Hannu Krosing:
> > > => commit;
> > > ROLLBACK
> > >
> >
> > Return status tells you what actually happened.
>
> If I send a COMMIT, I want a commit to happen or an error.
Yo
Am Freitag, 17. März 2006 13:03 schrieb Hannu Krosing:
> > If I send a COMMIT, I want a commit to happen or an error.
>
> You already got several errors.
Right, but a defensively programmed application, I want to get all the errors
all the time at every possible place.
> Or would you like a mode
Ühel kenal päeval, R, 2006-03-17 kell 14:10, kirjutas Peter Eisentraut:
> Am Freitag, 17. März 2006 13:03 schrieb Hannu Krosing:
> > > If I send a COMMIT, I want a commit to happen or an error.
> >
> > You already got several errors.
>
> Right, but a defensively programmed application, I want to g
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> So what's the difference between these two strategy?
> (1) Running time: do they use the same amount of memory? Why option 2 is
> better than 1?
> (2) Idle time: after sort done, option 1 will return all 1024 to the OS and
> 2 will still keep 512?
Poin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 17. März 2006 13:03 schrieb Hannu Krosing:
>> Or would you like a mode where you need explicitly send a ROLLBACK to
>> get out ?
> I faintly recall that this used to be the behavior.
No, it never was like that, and I don't think we can c
> My own thoughts about the problems with our work_mem arrangement are
> that the real problem is the rule that we can allocate work_mem per sort
> or hash operation; this makes the actual total memory use per backend
> pretty unpredictable for nontrivial queries. I don't know how to fix
> this th
Am Freitag, 17. März 2006 16:07 schrieb Tom Lane:
> It would also move us further away from the SQL standard. The spec says
> that COMMIT ends the transaction, full stop, not "ends it only if you're
> not in an error state". Of course the spec hasn't got a notion of a
> transaction error state at
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 17. März 2006 16:07 schrieb Tom Lane:
>> It would also move us further away from the SQL standard. The spec says
>> that COMMIT ends the transaction, full stop, not "ends it only if you're
>> not in an error state". Of course the spec has
On 3/17/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > The standard does address the issue of transactions that cannot be committed
> > because of an error. In 16.6. GR 6 it basically says
> > that
> > if the transaction cannot be completed (here: because of a constraint
> > violation), then an exc
Someone sent the following request to the Debian bug tracking system:
"""
It'd be nice if the .psql_history file were per-database. This is
because the commands executed on different databases are likely to be
very different, so there is no good reason to lose history for db1 when
working with db2
Peter Eisentraut wrote:
> Someone sent the following request to the Debian bug tracking system:
>
> """
> It'd be nice if the .psql_history file were per-database. This is
> because the commands executed on different databases are likely to be
> very different, so there is no good reason to lose h
Bruce Momjian wrote:
> The psql manual pages for 8.1 now has:
> \set HISTFILE ~/.psql_history- :DBNAME
Excellent!
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9: In versions below 8.0, th
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > The psql manual pages for 8.1 now has:
>
> > \set HISTFILE ~/.psql_history- :DBNAME
>
> Excellent!
Yea, it is a cool trick someone posted once and I added it to the manual
page for others to use.
--
Bruce Momjian http://candl
2006/3/17, Bruce Momjian :
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > The psql manual pages for 8.1 now has:
> >
> > > \set HISTFILE ~/.psql_history- :DBNAME
Any reason psql doesn't do this by default? It is clear that the
database name does not unambiguously identify a
Markus Bertheau wrote:
> 2006/3/17, Bruce Momjian :
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > The psql manual pages for 8.1 now has:
> > >
> > > > \set HISTFILE ~/.psql_history- :DBNAME
>
> Any reason psql doesn't do this by default? It is clear that the
> databa
[EMAIL PROTECTED] ("Markus Bertheau") writes:
> 2006/3/17, Bruce Momjian :
>> Peter Eisentraut wrote:
>> > Bruce Momjian wrote:
>> > > The psql manual pages for 8.1 now has:
>> >
>> > > \set HISTFILE ~/.psql_history- :DBNAME
>
> Any reason psql doesn't do this by default? It is clear
Chris Browne wrote:
[EMAIL PROTECTED] ("Markus Bertheau") writes:
2006/3/17, Bruce Momjian :
Peter Eisentraut wrote:
Bruce Momjian wrote:
The psql manual pages for 8.1 now has:
\set HISTFILE ~/.psql_history- :DBNAME
Any reason psql
Tom,
> My own thoughts about the problems with our work_mem arrangement are
> that the real problem is the rule that we can allocate work_mem per sort
> or hash operation; this makes the actual total memory use per backend
> pretty unpredictable for nontrivial queries. I don't know how to fix
> t
Josh Berkus writes:
> Mind you, I'm also thinking that on enterprise installations with
> multi-department use of the database, the fact that work_mem is
> inalienably USERSET is also an allocation problem. One user with a SET
> command can blow all of your resource planning away.
One user w
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Chris Browne wrote:
>> [EMAIL PROTECTED] ("Markus Bertheau") writes:
>>> Any reason psql doesn't do this by default?
>>
>> I fairly frequently find myself accessing different (but similar)
>> databases, and it's quite valuable to be able to submit the *
Ühel kenal päeval, R, 2006-03-17 kell 09:46, kirjutas Tom Lane:
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > So what's the difference between these two strategy?
> > (1) Running time: do they use the same amount of memory? Why option 2 is
> > better than 1?
> > (2) Idle time: after sort done,
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Chris Browne wrote:
> >> [EMAIL PROTECTED] ("Markus Bertheau") writes:
> >>> Any reason psql doesn't do this by default?
> >>
> >> I fairly frequently find myself accessing different (but similar)
> >> databases, and it's quite valua
Hannu Krosing <[EMAIL PROTECTED]> writes:
> So perhaps we could keep the shaded_work_mem in actual shared memory,
> and alloc it to processes from there ?
No, that's utterly not reasonable, both from an allocation point of view
(you'd have to make shared memory enormous, and not all platforms will
On Friday 17 March 2006 10:55, Chris Browne wrote:
> [EMAIL PROTECTED] ("Markus Bertheau") writes:
> > 2006/3/17, Bruce Momjian :
> >> Peter Eisentraut wrote:
> >> > Bruce Momjian wrote:
> >> > > The psql manual pages for 8.1 now has:
> >> > >
> >> > > \set HISTFILE ~/.psql_history- :
On Fri, Mar 17, 2006 at 04:45:17PM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > So perhaps we could keep the shaded_work_mem in actual shared memory,
> > and alloc it to processes from there ?
>
> No, that's utterly not reasonable, both from an allocation point of view
>
Folks,
Wanted to update you on a few things regarding speaking at the upcoming
PostgreSQL Anniversary Summit:
-- There are only 13 days left to submit a proposal. Please do so. We'd
rather not be forced into a last-minute rush to evaluate all of the stuff
in April. Remember this is a "famil
Josh Berkus writes:
> -- There are only 13 days left to submit a proposal. Please do so. We'd
> rather not be forced into a last-minute rush to evaluate all of the stuff
> in April. Remember this is a "family" event so you don't have to have all
> of your materials together before you send s
Tom,
On 3/17/06 7:03 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Speaking of which, I've been trying to think of a talk proposal and am
> not coming up with anything that seems terribly sexy. I've talked a
> couple times about the planner and am afraid people would be bored by
> that again. I'd
Csaba,
On 3/17/06 7:07 AM, "Csaba Nagy" <[EMAIL PROTECTED]> wrote:
> It worths a look at how apache Derby does with query planning, where a
> planned query is actually a compiled Java class, i.e. the executable
> byte code which will run to fetch the results, created and compiled by
> the planner
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> What would people like to hear about?
>
I am really interested in the concurrency control part of the PostgreSQL. I
can see the MVCC/lock rules there, and basically I can follow them -- but
there are so many if-else in the rules, so the problem always for
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> We've looked at using the open source llvm compiler to create an
> intermediate representation of the plan, then generate machine code and
> dispatch for execution.
This would buy what exactly?
regards, tom lane
--
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> What would people like to hear about?
> I am really interested in the concurrency control part of the PostgreSQL.
Hm, I already talked about that once:
http://www.postgresql.org/files/developer/transactions.pdf
Tom,
Luke Lonergan wrote:
>>I figure I can back it up...). What would people like to hear about?
>
> How about future plans, so to speak? You've made some pretty significant
> improvements for 8.1 (virtual tuples, the caching algorithm, etc), what's on
> deck for 8.2 and beyond?
I'm *really* *
37 matches
Mail list logo
