On Wed, Aug 3, 2011 at 8:33 PM, Tom Lane wrote:
> Simon Riggs writes:
>> I think its possible to tell automatically whether we need to replan
>> always or not based upon the path we take through selectivity
>> functions.
>
> I don't really believe that, or at least I think it would only detect a
Peter Geoghegan writes:
> On 3 August 2011 21:03, Tom Lane wrote:
>> I mean that it's unclear what you'll get if status has a bitpattern
>> equivalent to a negative integer. If the compiler implements the
>> comparison as signed, the test will yield TRUE; if unsigned, it's FALSE.
> On compilers
On 04.08.2011 04:21, David Fetter wrote:
On Wed, Aug 03, 2011 at 01:40:42PM +0300, Heikki Linnakangas wrote:
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be give
On Wed, Aug 3, 2011 at 6:21 PM, Jim Nasby wrote:
> On Aug 3, 2011, at 1:21 PM, Robert Haas wrote:
>> 1. "We configure PostgreSQL to use a 2 Gbyte application-level cache
>> because PostgreSQL protects its free-list with a single lock and thus
>> scales poorly with smaller caches." This is a compl
Excerpts from Jim Nasby's message of mié ago 03 18:05:21 -0400 2011:
> Not sure how much this relates to this discussion, but I have often wished we
> had AFTER FOR EACH STATEMENT triggers that provided OLD and NEW recordsets
> you could make use of. Sometimes it's very valuably to be able to lo
On Wed, Aug 03, 2011 at 01:40:42PM +0300, Heikki Linnakangas wrote:
> On 03.08.2011 13:05, Peter Geoghegan wrote:
> >I don't believe that the standard allows for an implementation of
> >enums as unsigned integers - after all, individual enum literals can
> >be given corresponding negative integer v
On Wed, Aug 3, 2011 at 6:05 PM, Jim Nasby wrote:
> Not sure how much this relates to this discussion, but I have often wished we
> had AFTER FOR EACH STATEMENT triggers that provided OLD and NEW recordsets
> you could make use of. Sometimes it's very valuably to be able to look at
> *all* the r
On Wed, Aug 3, 2011 at 5:35 PM, Tom Lane wrote:
> That still seems utterly astonishing to me. We're touching each of
> those files once per query cycle; a cycle that contains two message
> sends, who knows how many internal spinlock/lwlock/heavyweightlock
> acquisitions inside Postgres (some of w
I have not explained well what I have in my mind in first message.
Main goal is more buffers to stay dirty in memory for longer time. So
checkpoint segments have to be 2, 3... times than in current approach. And
separate parameter can control how much buffers to write at once. DBA can
tune:
- chec
On 3 August 2011 21:03, Tom Lane wrote:
> I mean that it's unclear what you'll get if status has a bitpattern
> equivalent to a negative integer. If the compiler implements the
> comparison as signed, the test will yield TRUE; if unsigned, it's FALSE.
On compilers on which the enum value is repr
James Robinson writes:
> Python's getattr() allows for dynamic lookup of attributes on an
> object, as in:
> inst = MyClass(x=12, y=24)
> v = getattr(inst, 'x')
> assert v == 12
> Oftentimes in writing data validating trigger functions, it'd be real
> handy to be able to do
On Wed, Aug 03, 2011 at 04:03:39PM -0400, Tom Lane wrote:
> The C standard specifies that signed-to-unsigned conversions must work
> like that; and even if the standard didn't, it would surely work like
> that on any machine with two's-complement representation, which is to
> say every computer bui
On Aug 3, 2011, at 1:21 PM, Robert Haas wrote:
> 1. "We configure PostgreSQL to use a 2 Gbyte application-level cache
> because PostgreSQL protects its free-list with a single lock and thus
> scales poorly with smaller caches." This is a complaint about
> BufFreeList lock which, in fact, I've seen
On Aug 2, 2011, at 7:09 AM, Simon Riggs wrote:
>> The best compression and flexibility in
>>> that case is to store a bitmap since that will average out at about 1
>>> bit per row, with variable length bitmaps. Which is about 8 times
>>> better compression ratio than originally suggested, without
Simon Riggs writes:
> What seems strange is that we make no attempt to check whether we have
> already identified all tuples being removed by the VACUUM. We have the
> number of dead tuples we are looking for and we track the number of
> tuples we have deleted from the index, so we could easily ma
Hackers,
Python's getattr() allows for dynamic lookup of attributes on an
object, as in:
inst = MyClass(x=12, y=24)
v = getattr(inst, 'x')
assert v == 12
Oftentimes in writing data validating trigger functions, it'd be real
handy to be able to do a similar thing in
Robert Haas writes:
> On Wed, Aug 3, 2011 at 4:38 PM, Tom Lane wrote:
>> ... We could possibly accept stale values for the
>> planner estimates, but I think heapam's number had better be accurate.
> I think the exact requirement is that, if the relation turns out to be
> larger than the size we
Excerpts from Dean Rasheed's message of sáb jul 23 04:37:06 -0400 2011:
> On 22 July 2011 22:28, Robert Haas wrote:
> >> mine was that we need a command such as
> >>
> >> ALTER TABLE foo ALTER COLUMN bar SET NOT NULL name_of_notnull_constr
> >>
> >> where the last bit is what's new.
> >
> > Well,
On Wed, Aug 3, 2011 at 12:33 PM, Pavan Deolasee
wrote:
>
>
> The only problem, other than a surprising behavior that you noted,
> that I see with this approach is that we might repeatedly try to
> truncate a relation which in fact does not have anything to truncate.
> The worst thing is we might
On Wed, Aug 3, 2011 at 4:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane wrote:
>>> (If the query ended up being a seqscan, I'd expect a second
>>> lseek(SEEK_END) when the executor starts up, but I gather from the other
>>> complaints that the mosbench p
During btvacuumscan(), we lock the index for extension and then wait
to acquire a cleanup lock on the last page. Then loop until we find a
point where the index has not expanded again during our wait for lock
on that last page. On a busy index this can take some time, especially
when people regular
Robert Haas writes:
> On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane wrote:
>> (If the query ended up being a seqscan, I'd expect a second
>> lseek(SEEK_END) when the executor starts up, but I gather from the other
>> complaints that the mosbench people were only testing simple indexscan
>> queries.)
On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On a straight pgbench -S test, you get four system calls per query:
>> recvfrom(), lseek(), lseek(), sendto(). Adding -M prepared eliminates
>> the two lseeks.
>
> [ scratches head... ] Two?
Yep.
> Is that one for the ta
Peter Geoghegan writes:
> On 3 August 2011 15:29, Tom Lane wrote:
>> There is another point here, though, which is that if we're not sure
>> whether the compiler considers ExecStatusType to be signed or unsigned,
>> then we have no idea what the test "status < PGRES_EMPTY_QUERY" even
>> means.
>
Robert Haas writes:
> On a straight pgbench -S test, you get four system calls per query:
> recvfrom(), lseek(), lseek(), sendto(). Adding -M prepared eliminates
> the two lseeks.
[ scratches head... ] Two? Is that one for the table and one for its
lone index, or are we being redundant there?
Simon Riggs writes:
> I think its possible to tell automatically whether we need to replan
> always or not based upon the path we take through selectivity
> functions.
I don't really believe that, or at least I think it would only detect a
few cases. Examples of parameter-value-sensitive decisio
On Wed, Aug 3, 2011 at 3:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> This seems like a good design. Now what would be really cool is if
>> you could observe a stream of queries like this:
>
>> SELECT a, b FROM foo WHERE c = 123
>> SELECT a, b FROM foo WHERE c = 97
>> SELECT a, b FROM foo WHE
On Aug 3, 2011, at 11:28 AM, Grzegorz Jaskiewicz wrote:
> export CC=clang
> ./configure
> ...
Thanks, I'll give that a try the next time I build (RC1 I guess).
David
Robert Haas writes:
> This seems like a good design. Now what would be really cool is if
> you could observe a stream of queries like this:
> SELECT a, b FROM foo WHERE c = 123
> SELECT a, b FROM foo WHERE c = 97
> SELECT a, b FROM foo WHERE c = 236
> ...and say, hey, I could just make a generi
On Wed, Aug 3, 2011 at 2:49 PM, Tom Lane wrote:
> Martijn van Oosterhout writes:
>> On Wed, Aug 03, 2011 at 02:21:25PM -0400, Robert Haas wrote:
>>> It would be nice if the Linux guys would fix this problem for us, but
>>> I'm not sure whether they will. For those who may be curious, the
>>> pro
On 3 Aug 2011, at 19:20, David E. Wheeler wrote:
>
> Yeah, not sure whether or not to tweak the Makefile to use Clang. I guess not?
>
export CC=clang
./configure
...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mar ago 02 22:46:55 -0400 2011:
>
> > I have created a documentation patch to clarify this, and to mention
> > CREATE TABLE AS which also has this optimization.
>
> It doesn't seem particularly better to me. How about something lik
Martijn van Oosterhout writes:
> On Wed, Aug 03, 2011 at 02:21:25PM -0400, Robert Haas wrote:
>> It would be nice if the Linux guys would fix this problem for us, but
>> I'm not sure whether they will. For those who may be curious, the
>> problem is in generic_file_llseek() in fs/read-write.c. O
Tom Lane writes:
> So yes, it'd get a little worse for that use-case. But you have to
> weigh that against the likelihood that other use-cases will get better.
> If our requirement for a transient-plan mechanism is that no individual
> case can ever be worse than before, then we might as well aba
On Wed, Aug 03, 2011 at 02:21:25PM -0400, Robert Haas wrote:
> It would be nice if the Linux guys would fix this problem for us, but
> I'm not sure whether they will. For those who may be curious, the
> problem is in generic_file_llseek() in fs/read-write.c. On a platform
> with 8-byte atomic rea
About nine months ago, we had a discussion of some benchmarking that
was done by the mosbench folks at MIT:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00160.php
Although the authors used PostgreSQL as a test harness for driving
load, it's pretty clear from reading the paper that thei
On Aug 3, 2011, at 11:17 AM, Peter Eisentraut wrote:
> Note that what you are using there is a GCC frontend with a LLVM
> backend. (So I suppose you would get mostly GCC warnings.) Clang is a
> new/different compiler frontend using the LLVM backend.
Yeah, not sure whether or not to tweak the Ma
Excerpts from Alvaro Herrera's message of mié ago 03 13:12:38 -0400 2011:
> ... ah, maybe what we could do is have gram.y create a ColumnDef in the
> new production, and stick that in cmd->def instead of the list of
> constraints. So parse_utilcmd would have to know that if that node
> IsA(Column
On ons, 2011-08-03 at 10:33 -0700, David E. Wheeler wrote:
> I haven't been paying attention to warnings, but FWIW 9.1beta3 has
> been building with LLVM by default with Xcode 4. Both on Snow Leopard
> and on Lion I saw something like this:
>
> try=# select version();
>
> version
On ons, 2011-08-03 at 10:25 +0100, Peter Geoghegan wrote:
> Attached patch removes the tautologolical part of an evaluated
> expression, fixing the problem flagged by this quite valid warning.
I think these warnings are completely bogus and should not be worked
around. Even in the most trivial ca
On Aug 3, 2011, at 1:47 AM, Peter Geoghegan wrote:
> So, there are 4 remaining warnings.
I haven't been paying attention to warnings, but FWIW 9.1beta3 has been
building with LLVM by default with Xcode 4. Both on Snow Leopard and on Lion I
saw something like this:
try=# select version();
On Wed, Aug 3, 2011 at 12:27 PM, Florian Pflug wrote:
> Going down that road opens the door to a *lot* of subtle semantic
> differences between currently equivalent queries. For example,
>
> UPDATE T SET f=f, a=1
>
> would behave differently then
>
> UPDATE T SET a=1
>
> because in the first cas
Excerpts from Dean Rasheed's message of mié ago 03 03:11:32 -0400 2011:
> On 3 August 2011 04:40, Alvaro Herrera wrote:
> > Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
> >
> >> Looks pretty good to me (not too dirty). I suppose given that the
> >> parser transforms AT_C
Florian Pflug wrote:
> To me, it still seems conceptionally cleaner to just decree that a
> row must not be modified while BEFORE triggers are running,
> period.
>
> This, BTW, also matches what Oracle does, only on a per-row
> instead of per-table basis. Oracle AFAIR simply forbids touching
>
On Wed, Aug 3, 2011 at 12:19 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> Anyone have an opinion about that?
>
>> I still have this application where PREPARE takes between 50ms and 300ms
>> and EXECUTE 5ms to 10ms, and I can handle 1 PREPARE for 1 EXECUTE
>> quite e
Excerpts from Robert Haas's message of mié ago 03 12:14:15 -0400 2011:
> On Wed, Jul 27, 2011 at 7:16 PM, Alvaro Herrera
> wrote:
> > One thing I have not addressed is Noah's idea about creating a new lock
> > mode, KEY UPDATE, that would let us solve the initial problem that this
> > patch set to
Robert Haas wrote:
> Florian Pflug wrote:
>> Here's a step-by-step description of what happens in the case of
>> two UPDATES, assuming that we don't ignore any updated and throw
>> no error.
>>
>> 1) UPDATE T SET ... WHERE ID=1
>> 2) Row with ID=1 is found & locked
>> 3) BEFORE UPDATE triggers
On Aug3, 2011, at 17:57 , Robert Haas wrote:
> On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug wrote:
>> The different between Kevin's original patch and my suggestion is, BTW,
>> that he made step (7) through an error while I suggested the error to
>> be thrown already at (4).
>
> I think Kevin's
(moving this to hackers since I suspect we got an issue to fix here)
On Wed, Aug 3, 2011 at 6:35 AM, Sergey Konoplev wrote:
> Hi all,
>
> I have PostgreSQL 9.0.3 installed on my Gentoo Linux box. The
> configuration is default. There is no any activity in the database but
> the described below.
>
On 03.08.2011 11:18, Alexander Korotkov wrote:
I found that in previous version of patch I missed PageSetLSN
and PageSetTLI, but huge amount of WAL is still here. Also I found that huge
amount of WAL appears only with -O2. With -O0 amount of WAL is ok, but
messages "FATAL: xlog flush request BFF
On Aug3, 2011, at 17:55 , Robert Haas wrote:
> On that note, I think in some ways the problems we're hitting here are
> very much like serialization anomalies.
Yeah, I had the same feeling of familiarity ;-)
> If the user updates a tuple
> based on its PK and sets some non-PK field to a constant,
Dimitri Fontaine writes:
> Tom Lane writes:
>> Anyone have an opinion about that?
> I still have this application where PREPARE takes between 50ms and 300ms
> and EXECUTE 5ms to 10ms, and I can handle 1 PREPARE for 1 EXECUTE
> quite easily. (Yes the database fits in RAM, and yes when that's
On Wed, Jul 27, 2011 at 7:16 PM, Alvaro Herrera
wrote:
> One thing I have not addressed is Noah's idea about creating a new lock
> mode, KEY UPDATE, that would let us solve the initial problem that this
> patch set to resolve in the first place. I am not clear on exactly how
> that is to be imple
2011/7/29 Greg Smith :
> 1) Postponing writes as long as possible always improves the resulting
> throughput of those writes. Any incremental checkpoint approach will detune
> throughput by some amount. If you make writes go out more often, they will
> be less efficient; that's just how things wo
On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug wrote:
> On Aug3, 2011, at 04:54 , Robert Haas wrote:
>> On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
>> wrote:
> Would you feel comfortable with a patch which threw an error on
> the DELETE case, as it does on the UPDATE case?
Yes
On Wed, Aug 3, 2011 at 10:48 AM, Kevin Grittner
wrote:
> As have many other data mangling bugs which we fix in minor
> releases. Our point here is that it's never been like this in any
> product that the Wisconsin Courts has used for triggers, and never
> will be.
I don't believe this is very si
On 3 August 2011 15:29, Tom Lane wrote:
> No, this is not an improvement at all. The point of the code is that we
> are about to use the enum value as an integer array subscript, and we
> want to make sure it is within the array bounds. Tying that logic to
> some member of the enum is not a read
daveg writes:
> We have installed the patch and have encountered the error as usual.
> However there is no additional output from the patch. I'm speculating
> that the pg_class scan in ScanPgRelationDetailed() fails to return
> tuples somehow.
Evidently not, if it's not logging anything, but now
Robert Haas wrote:
> Kevin Grittner wrote:
Would you feel comfortable with a patch which threw an error on
the DELETE case, as it does on the UPDATE case?
>>>
>>> Yes, though with a little additional twist. The twist being that
>>> I'd like the error to be thrown earlier, at the time
Peter Geoghegan writes:
> On 3 August 2011 12:19, Heikki Linnakangas
> wrote:
>> Right, but the purpose of that check is to defend from programmer error. If
>> the programmer screws up and calls "PQresStatus(-1)", we want to give an
>> error, not crash. If you assume that the programmer will only
It occurred to me that you may be a little surprised that the patch
actually prevents the warning from occurring. If you have any doubts,
I can assure you that it does. Clang differentiates between 0 as an
rvalue, 0 from an enum literal and 0 resulting from evaluating a macro
expression (including
Robert Haas writes:
> On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane wrote:
>> Maybe. But if that's the approach we want to use, let's just call it
>> pg_erand48 in the code, and dispense with the alias macros as well as
>> all vestiges of configure support.
> Works for me. Just to confirm, that mea
On Wed, Aug 3, 2011 at 4:18 AM, Alexander Korotkov wrote:
> I found that in previous version of patch I missed PageSetLSN
> and PageSetTLI, but huge amount of WAL is still here. Also I found that huge
> amount of WAL appears only with -O2. With -O0 amount of WAL is ok, but
> messages "FATAL: xlog
Tom Lane writes:
> Anyone have an opinion about that?
I still have this application where PREPARE takes between 50ms and 300ms
and EXECUTE 5ms to 10ms, and I can handle 1 PREPARE for 1 EXECUTE
quite easily. (Yes the database fits in RAM, and yes when that's no
longer the case we just upgrade
On Mon, Aug 01, 2011 at 01:23:49PM -0400, Tom Lane wrote:
> daveg writes:
> > On Sun, Jul 31, 2011 at 11:44:39AM -0400, Tom Lane wrote:
> >> I think we need to start adding some instrumentation so we can get a
> >> better handle on what's going on in your database. If I were to send
> >> you a so
On 3 August 2011 12:19, Heikki Linnakangas
wrote:
> Right, but the purpose of that check is to defend from programmer error. If
> the programmer screws up and calls "PQresStatus(-1)", we want to give an
> error, not crash. If you assume that the programmer will only pass a valid
> enum constant a
On 03.08.2011 14:13, Peter Geoghegan wrote:
On 3 August 2011 11:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
It actually gives l
On 3 August 2011 11:05, Peter Geoghegan wrote:
> I don't believe that the standard allows for an implementation of
> enums as unsigned integers - after all, individual enum literals can
> be given corresponding negative integer values.
It actually gives leeway to implement the enum as unsigned in
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
C99 says:
Each enumerated type shall be compatible with char, a si
On 3 August 2011 10:34, Heikki Linnakangas
wrote:
> The check is only tautological if the compiler implements enums as unsigned
> integers. Whether enums are signed or not is implementation-dependent.
> Perhaps cast status to unsigned or signed explicitly before the checks?
I don't believe that t
On 03.08.2011 12:25, Peter Geoghegan wrote:
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
The check is only tautological if the compiler implements enums as
unsigned integers. Whether enums are signed or not i
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git a/src/interfaces/libpq/fe-exec.c b/src/int
On Aug3, 2011, at 04:54 , Robert Haas wrote:
> On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
> wrote:
Would you feel comfortable with a patch which threw an error on
the DELETE case, as it does on the UPDATE case?
>>>
>>> Yes, though with a little additional twist. The twist being that
On 3 August 2011 00:52, Peter Geoghegan wrote:
> Now, the only warning that remains is that same
Correction - there are actually 3 additional warnings like this in repl_gram.c:
/home/peter/build/Release/bin/clang -O2 -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendi
I found that in previous version of patch I missed PageSetLSN
and PageSetTLI, but huge amount of WAL is still here. Also I found that huge
amount of WAL appears only with -O2. With -O0 amount of WAL is ok, but
messages "FATAL: xlog flush request BFF11148/809A600 is not satisfied ---
flushed only t
On 3 August 2011 04:40, Alvaro Herrera wrote:
> Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
>
>> Looks pretty good to me (not too dirty). I suppose given that the
>> parser transforms AT_ColumnConstraint into one of the existing command
>> subtypes, you could just have
76 matches
Mail list logo
