2009/5/12 Hitoshi Harada :
> 2009/5/11 Pavel Stehule :
>> I am thinking so Grouping Sets based on CTE should be more commitable
>> code. It doesn't mean so your ideas are wrong, but these
>> optimalization should to work on CTE too.
>>
>> select * from table group by rollup(a,b,c)
>>
>> have to hav
My sincere apologies for flooding your mailboxes once again, as the
patch attached in the previous post was incorrect. Also, I had failed
to show test-cases of \d in both 8.4 and 8.3 servers.
Attached are the test cases for psql connecting to 8.4 and 8.3.
psql (8.4beta1)
Type "help" for help.
p
Hi,
FORCE QUOTE option of COPY WITH CSV requires an explicit column list,
but '*' (all columns) would be also useful for typical usages.
I searched the ML archive and found one request before:
| COPY TO with FORCE QUOTE *
| http://archives.postgresql.org/pgsql-sql/2008-08/msg00084.php
The attach
>> On Tue, May 12, 2009 at 12:20 AM, Tom Lane wrote:
>>>
>>> Index "public.fooi"
>>> Column | Type | Definition
>>> -+-+
>>> f1 | integer | f1
>>> pg_expression_2 | integer | (f2+f3)
>
Hi,
I'd agree that the mucking around wi
2009/5/11 Pavel Stehule :
> I am thinking so Grouping Sets based on CTE should be more commitable
> code. It doesn't mean so your ideas are wrong, but these
> optimalization should to work on CTE too.
>
> select * from table group by rollup(a,b,c)
>
> have to have generate same plan as
>
> with q a
I wrote:
> it seems that there is a reasonably simple solution: we could make
> find_inheritance_children() and find_all_inheritors() acquire lock
> on each child table as they scan pg_inherits, and do try_relation_open()
> or equivalent to see if the child still exists. If not, assume the
> table
On 5/11/09 4:25 PM, Tom Lane wrote:
Josh Berkus writes:
I can see Zoltan's argument: for web applications, it's important to
keep the *total* wait time under 50 seconds for most users (default
browser timeout for most is 60 seconds).
And why is that only about lock wait time and not about tot
Greg Stark writes:
> On Tue, May 12, 2009 at 12:20 AM, Tom Lane wrote:
>>
>> Index "public.fooi"
>> Column | Type | Definition
>> -+-+
>> f1 | integer | f1
>> pg_expression_2 | integer | (f2+f3)
> Is there any reason to expo
Josh Berkus writes:
> I can see Zoltan's argument: for web applications, it's important to
> keep the *total* wait time under 50 seconds for most users (default
> browser timeout for most is 60 seconds).
And why is that only about lock wait time and not about total execution
time? I still thin
On Tue, May 12, 2009 at 12:20 AM, Tom Lane wrote:
>
> Index "public.fooi"
> Column | Type | Definition
> -+-+
> f1 | integer | f1
> pg_expression_2 | integer | (f2+f3)
Is there any reason to expose "pg_expression_2" to the use
Alvaro Herrera writes:
> Khee Chin escribió:
>> Updated with an additional line in the comments for get_indexdef
>>
>> * if colno == -999, we only want the name of the variables that
>> make up the index
> I don't think this hack is going to fly.
Yeah ... if it were local in describe.c tha
Tom,
My point is that I don't believe the scenario where you say that you
know exactly how long each different statement in your application
should wait and they should all be different. What I do find credible
is that you want to set a "policy" for all the lock timeouts. Now
think about what
Khee Chin escribió:
> Updated with an additional line in the comments for get_indexdef
>
> * if colno == -999, we only want the name of the variables that
> make up the index
I don't think this hack is going to fly. I suggest you need to find
some other way to implement this.
--
Alvaro He
Robert Haas writes:
> I kinda agree with this. I believe Tom was arguing upthread that any
> change of this short should touch all of the places where NOWAIT is
> accepted now, and I agree with that. But having to issue SET as a
> separate statement and then maybe do another SET afterward to get
Josh Berkus írta:
>
>> But more generally, what you are proposing seems largely duplicative
>> with statement_timeout. The only reason I can see for a
>> lock-wait-specific timeout is that you have a need to control the
>> length of a specific wait and *not* the overall time spent. Hans
>> alread
But more generally, what you are proposing seems largely duplicative
with statement_timeout. The only reason I can see for a
lock-wait-specific timeout is that you have a need to control the
length of a specific wait and *not* the overall time spent. Hans
already argued upthread why he wants a
2009/5/11 Hans-Jürgen Schönig :
> i agree that a GUC is definitely an option.
> however, i would say that adding an extension to SELECT FOR UPDATE, UPDATE
> and DELETE would make more sense form a usability point of view (just my
> 0.02 cents).
I kinda agree with this. I believe Tom was arguing u
Greg Stark írta:
> 2009/5/11 Boszormenyi Zoltan :
>
>> Does statement_timeout counts against subtransactions as well? No.
>> If a statement finishes before statement_timeout, does it also decrease
>> the possible runtime for the next statement? No. I was talking about
>> locks acquired during on
hello tom ...
the reason for SELECT FOR UPDATE is very simple:
this is the typical lock obtained by basically every business
application if written properly (updating a product, whatever).
the problem with NOWAIT basically is that if a small transaction holds
a a lock for a subsecond, you wil
2009/5/11 Boszormenyi Zoltan :
> Does statement_timeout counts against subtransactions as well? No.
> If a statement finishes before statement_timeout, does it also decrease
> the possible runtime for the next statement? No. I was talking about
> locks acquired during one statement.
With respect I
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> I think the way you're describing would be both harder to implement
>>> and full of its own strange traps.
>>>
>
>
>> Why?
>>
>
> Well, for one thing: if I roll back a subtransaction, should the lock
> wa
Boszormenyi Zoltan writes:
> Tom Lane írta:
>> I think the way you're describing would be both harder to implement
>> and full of its own strange traps.
> Why?
Well, for one thing: if I roll back a subtransaction, should the lock
wait time it used now no longer count against the total? If not,
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Would the "lock_timeout" work for all to be acquired locks individually,
>> or all of them combined for the statement? The individual application
>> of the timeout for every locks individually wouldn't be too nice.
>>
>
> I think the way you
Boszormenyi Zoltan writes:
> Would the "lock_timeout" work for all to be acquired locks individually,
> or all of them combined for the statement? The individual application
> of the timeout for every locks individually wouldn't be too nice.
I think the way you're describing would be both harder
Hi,
Tom Lane írta:
> Hans-Juergen Schoenig writes:
>
>> i would like to propose an extension to our SELECT FOR UPDATE mechanism.
>> especially in web applications it can be extremely useful to have the
>> chance to terminate a lock after a given timeframe.
>>
>
> I guess my immediate rea
Peter Eisentraut wrote:
> On Monday 11 May 2009 11:02:17 Magnus Hagander wrote:
>> Another thought: if we were to make ourselves support multiple SSL
>> libraries (that has been suggested before - at that point, people wanted
>> GnuTLS), we could also add support for Windows SChannel, which I'm sur
On Monday 11 May 2009 11:02:17 Magnus Hagander wrote:
> Another thought: if we were to make ourselves support multiple SSL
> libraries (that has been suggested before - at that point, people wanted
> GnuTLS), we could also add support for Windows SChannel, which I'm sure
> some win32 people would c
There was just another complaint about something we've heard about
before, namely that dropping a child table doesn't interact nicely
with queries concurrently accessing the parent table:
http://archives.postgresql.org/pgsql-bugs/2009-05/msg00113.php
As I responded there, this isn't fixable by the
In message <20090511144317.gc8...@alvh.no-ip.org>, Alvaro Herrera writes:
Magnus Hagander wrote:
> Another thought: if we were to make ourselves support multiple SSL
> libraries (that has been suggested before - at that point, people wanted
> GnuTLS), we could also add suppor
In message <4a07db89.2080...@hagander.net>, Magnus Hagander writes:
Is NSS available on all the platforms that we are (and that has OpenSSL
today)?
NSS stopped publishing their supported platform list for NSS for some
strange reasons (older version have it). But I'd probably assume that
Tom Lane wrote:
> Alvaro Herrera writes:
>> Magnus Hagander wrote:
>>> Applied, thanks!
>
>> Shouldn't this be backpatched?
>
> It looks like a feature change to me ...
Yup, I think so too. It changes the behavior if you have such a file.
//Magnus
--
Sent via pgsql-hackers mailing list (pgs
Greg Stark wrote:
> Kevin Grittner wrote:
>> Greg Stark wrote:
>>
>>> I thought the big problem with providing true serializability was
>>> the predicate locking. If it doesn't address that need then does
>>> this get us any closer?
>>
>> I thought the big problem was the perception that perfor
Alvaro Herrera writes:
> Magnus Hagander wrote:
>> Applied, thanks!
> Shouldn't this be backpatched?
It looks like a feature change to me ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Hans-Juergen Schoenig writes:
> i would like to propose an extension to our SELECT FOR UPDATE mechanism.
> especially in web applications it can be extremely useful to have the
> chance to terminate a lock after a given timeframe.
I guess my immediate reactions to this are:
1. Why SELECT FOR UP
Magnus Hagander wrote:
> Another thought: if we were to make ourselves support multiple SSL
> libraries (that has been suggested before - at that point, people wanted
> GnuTLS), we could also add support for Windows SChannel, which I'm sure
> some win32 people would certainly prefer - much easier
Magnus Hagander wrote:
> Andrew Gierth wrote:
> > Magnus asked me for this, when the subject came up on IRC. This is a
> > longstanding ignored issue, for example
> > http://archives.postgresql.org/message-id/slrnemslp5.2rcr.andrew+non...@atlantis.supernews.net
> > http://archives.postgresql.org/me
"Albe Laurenz" wrote:
> In my first reply I wondered if the presence of concurrent "read
> committed" transactions would somehow affect the correctness of the
> algorithm, as the authors don't mention that.
Yeah, I was concerned about that, too. In thinking it through I've
convinced myself th
On Mon, May 11, 2009 at 3:11 PM, Kevin Grittner
wrote:
> Greg Stark wrote:
>
>> I thought the big problem with providing true serializability was
>> the predicate locking. If it doesn't address that need then does
>> this get us any closer?
>
> I thought the big problem was the perception that pe
Greg Stark wrote:
> I thought the big problem with providing true serializability was
> the predicate locking. If it doesn't address that need then does
> this get us any closer?
I thought the big problem was the perception that performance would
suffer and that the level of blocking required
Kevin Grittner wrote:
> > All the authors show with regard to predicate handling is
> > handwaving,
>
> That is because predicate locking is a mature technology with many
> known implementations. The best technique for any database product
> will depend on that product, and their technique doesn
On Mon, May 11, 2009 at 2:49 PM, Kevin Grittner
wrote:
> "Albe Laurenz" wrote:
>
>> All the authors show with regard to predicate handling is
>> handwaving,
>
> That is because predicate locking is a mature technology with many
> known implementations. The best technique for any database product
"Albe Laurenz" wrote:
> All the authors show with regard to predicate handling is
> handwaving,
That is because predicate locking is a mature technology with many
known implementations. The best technique for any database product
will depend on that product, and their technique doesn't depend
We are looking for an experienced Postgresql DBA willing to travel and
provide short and tailored Postgresql training as well as develop an
interface in VB or VB.NET for data capture and query postgresql database.
The application shall be client server.
Immediate, 10 days assignment all costs cover
Tom Lane wrote:
> "Erik Rijkers" writes:
> > On Sun, May 10, 2009 02:05, Alvaro Herrera wrote:
> >> I'm wondering that it could have forgotten to migrate the later table
> >> segments ...
>
> > It seems al 'truncated' tables give
> > pg_relation_size(oid) = 1073741824
>
> Looks like Alvaro naile
I tend to think there should be protocol level support for options
like this but that would require buy-in from the interface writers.
how would you do it?
if you support it on the protocol level, you still need a way to allow
the user to tell you how ...
i would see WAIT for DELETE, UP
--
Greg
On 11 May 2009, at 11:18, Hans-Juergen Schoenig
wrote:
hello greg,
the thing with statement_timeout is a little bit of an issue.
you could do:
SET statement_timeout TO ...;
SELECT FOR UPDATE ...
SET statement_timeout TO default;
this practically means 3 commands.
I t
--On 11. Mai 2009 06:38:44 -0300 Lucas Brito wrote:
Why not extend the "SET" instruction to allow configuration parameters to
be set only in the duration of the transaction or the next "n" commands?
It's already there: see SET LOCAL.
--
Thanks
Bernd
--
Sent via pgsql-hackers mail
2009/5/11 Hans-Juergen Schoenig
> the thing with statement_timeout is a little bit of an issue.
> you could do:
> SET statement_timeout TO ...;
> SELECT FOR UPDATE ...
> SET statement_timeout TO default;
>
Why not extend the "SET" instruction to allow configuration parameters to be
set on
hello greg,
the thing with statement_timeout is a little bit of an issue.
you could do:
SET statement_timeout TO ...;
SELECT FOR UPDATE ...
SET statement_timeout TO default;
this practically means 3 commands.
the killer argument, however, is that the lock might very well happen
ways af
--On Mittwoch, Mai 06, 2009 19:04:21 -0400 Tom Lane
wrote:
So I'm now persuaded that a better textual representation for bytea
should indeed make things noticeably better here. It would be
useful though to cross-check this thought by profiling a case that
dumps a comparable volume of text dat
Can't you to this today with statement_timeout? Surely you do want to
rollback the whole transaction or at least the subtransaction if you
have error handling.
--
Greg
On 11 May 2009, at 10:26, Hans-Juergen Schoenig
wrote:
hello everybody,
i would like to propose an extension to our
hello everybody,
i would like to propose an extension to our SELECT FOR UPDATE mechanism.
especially in web applications it can be extremely useful to have the
chance to terminate a lock after a given timeframe.
i would like to add this functionality to PostgreSQL 8.5.
the oracle syntax is qui
Seth Robertson wrote:
> In message <14727.1241816...@sss.pgh.pa.us>, Tom Lane writes:
>
> > It is of course possible to support both at the same time (at
> > compile-time, if nowhere else).
>
> Yes, I suppose we'd not wish to just drop openssl completely.
> I wonder how much c
Andrew Gierth wrote:
> Magnus asked me for this, when the subject came up on IRC. This is a
> longstanding ignored issue, for example
> http://archives.postgresql.org/message-id/slrnemslp5.2rcr.andrew+non...@atlantis.supernews.net
> http://archives.postgresql.org/message-id/15d55918-fa9c-4e6a-ba15-
Peter Eisentraut wrote:
> On Friday 08 May 2009 22:03:56 Tom Lane wrote:
>> I hesitate though to suggest that we think about porting
>> ourselves to NSS --- I'm not sure that there would be benefits to us
>> within the context of Postgres alone.
>
> That could be attractive if we ripped out the O
On Friday 08 May 2009 22:03:56 Tom Lane wrote:
> I hesitate though to suggest that we think about porting
> ourselves to NSS --- I'm not sure that there would be benefits to us
> within the context of Postgres alone.
That could be attractive if we ripped out the OpenSSL code at the same time,
as
Kevin Grittner wrote:
> > I still haven't actually read the paper so I should probably bow out
> > from the conversation until I do. I was apparently already under
> > one misapprehension as Laurenz just claimed the paper does not show
> > how to prevent "phantoms" (phantom reads I assume?). Perha
57 matches
Mail list logo
