Marko Tiikkaja wrote:
>On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
>>If you know beforehand the query might generate more than one row (SELECT)
>>yet you also know that you are not interested in those, then maxrows=1
>>is best; then again, modifying the query to incl
Andres Freund wrote:
>On 2015-02-03 12:26:33 +0100, Shay Rojansky wrote:
>> find a way to execute a query but without fetching any rows. The Execute
>> message has a maximum result-row count, but zero is documented to mean
>> "fetch all rows".
>Is this really a relevant optimization? If the user d
Shay Rojansky wrote:
>I'm working on the Npgsql, the .NET driver for PostgreSQL, and am trying to
>find a way to execute a query but without fetching any rows. The Execute
>message has a maximum result-row count, but zero is documented to mean
>"fetch all rows".
>The use case would be sending a qu
Jim Nasby wrote:
>Rather than trying to wedge this into a heap page, ISTM it'd be
>better to use a fork. Presumably if you're storing regular tuples
>that have the essential data from pg_class, pg_attribute (and maybe
>pg_type).
Well, three things:
- The information preferably is present in the sa
In relation to the talk and discussions at FOSDEM regarding
helping data recovery, I searched the archives for the
old thread after I performed my last recovery; for reference:
http://www.postgresql.org/message-id/20101019201223.ga15...@cuci.nl
I haven't checked yet if the proposed space there is
Florian Pflug wrote:
>> I used this to upgrade to 9.0.13, which indeed is fully compatible with
>> Debian. It started up like a charm. I can upgrade it to 9.1.9 now
>> (while I'm at it).
>Since you've been running with full_page_writes=off, I suggest you update
>to 9.1 by dumping and reloading y
Thanks, all of you, for all good advice and suggestions.
Andres Freund wrote:
>Afaik debian has never shipped 9.0 in any stable release at all. You can
>use the packages provided by the postgres community though, they are
>compatible:
>http://wiki.postgresql.org/wiki/Apt
I used this to upgrade to
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> Tom Lane wrote:
>>> It's conceivable that updating to something more current than 9.0.4
>>> would get you out of this --- we've fixed quite a number of WAL replay
>>> bugs in the last two
Andres Freund wrote:
>On 2013-04-09 18:21:20 +0200, Stephen R. van den Berg wrote:
>Thats an absolutely outdated version of 9.0. You shouldn't be running
>this in production.
Yes, well, it's one of those things. It got installed with Debian
and the automatic upgrade didn&#
Joshua D. Drake wrote:
>full_page_writes = off is the problem.
>Turning this parameter off speeds normal operation, but might lead to
>either unrecoverable data corruption, or silent data corruption,
>after a system failure. The risks are similar to turning off fsync,
>though smaller, and it shoul
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> Just today one of my systems experienced a kernel panic, and halted abruptly.
>> Running Linux 3.1.9, PostgreSQL 9.0.4 (Debian 9.0.4-1+b1, to be precise).
>It's conceivable that updating to something more curr
Just today one of my systems experienced a kernel panic, and halted abruptly.
Running Linux 3.1.9, PostgreSQL 9.0.4 (Debian 9.0.4-1+b1, to be precise).
The system was moderately active, i.e. about one commit per minute.
It is not a large problem if the last few commits would be gone.
Now, in rest
Bruce Momjian wrote:
>Greg Stark wrote:
>> On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg
>> wrote:
>> > In order to simplify recovery at this point (enormously), it would
>> > have been very helpful (at almost negligible cost), to have the name
&
Greg Stark wrote:
>On Thu, Oct 21, 2010 at 11:30 AM, Stephen R. van den Berg wrote:
>> For the recovery information I'd like to reserve:
>> identifier: 00: table OID
>> ? ? ? ? ? ?01: table layout
>So here's a proposal for something that could maybe be impleme
Kevin Grittner wrote:
>Tom Lane wrote:
>> Most of the data-loss reports I've seen appeared to come from
>> people who wouldn't be capable of doing such recovery work even if
>> better tools were available.
>No doubt; but the recovery work often winds up in the hands of
>people with more skills th
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> If it's inserted in the "special" area, it will not break any
>> compatibility.
>I'll tell you what I really don't like about this proposal: we discuss
>some scheme or other for taking
Robert Haas wrote:
>On Wed, Oct 20, 2010 at 5:30 PM, Stephen R. van den Berg wrote:
>> Ideal would be: put the table-oid inside the header of each page
>> (either in the official header, or in the special area).
>> This way even lost blocks can be correlated to the same tab
Tom Lane wrote:
>Aidan Van Dyk writes:
>> If we're looking to have any sort of "out of catalog" documentation of
>> table storage format, what about just having a new relation fork that
>> just "appends" each and every change made to the table formats,
>> including ones rolled back, etc.
I presum
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> It's just that matching table and file, and subsequently figuring out
>> some missing columns which may have been added/removed later,
>> can be rather timeconsuming and could be made a lot easier
Roberto Mello wrote:
>On Tue, Oct 19, 2010 at 6:13 PM, Stephen R. van den Berg wrote:
>> Greg Stark wrote:
>>>premise this on the idea that you've lost everything in the catalog
>>>but not the data in other tables. Which seems like a narrow use case.
>> I
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> In order to simplify recovery at this point (enormously), it would
>> have been very helpful (at almost negligible cost), to have the name
>> of the table, the name of the columns, and the types of the
>>
Greg Stark wrote:
>On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg wrote:
>> In order to simplify recovery at this point (enormously), it would
>> have been very helpful (at almost negligible cost), to have the name
>> of the table, the name of the columns,
I spent yesterday writing a new tool pg_rawdump (which will be released as
open source in due course), which takes the table files in an arbitrary
pgsql database, and is able to transform those back into tables (including
toast values).
In the course of doing this (a customer needed it because he
t connection is never closed.
Instead of keeping track of this fact, I'd presume that it'd be easier to
simply group all listens on a single connection outside the pool. So your
patch will not benefit any practical use cases I can think of.
--
Sincerely,
Stephen R. van den Be
t modification of table %',TG_ARGV[0];
END IF;
RETURN NEW;
END;$$ LANGUAGE PLPGSQL;
Which allows detection of concurrent updates on the same page (if the
lastupdate value is being fetched before the update-template is filled).
--
Sincerely,
Stephen R. van den Berg.
Auto repair r
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> BEGIN
>> vcsid:=vfrom;
>> LOOP
>> EXIT WHEN vsid IS NOT NULL OR vcsid=vold;
>> END LOOP;
>> RETURN vsid;
>> END;
>And are you certain that's never an infinite loop? The
Tom Lane wrote:
>"Stephen R. van den Berg" writes:
>> It seems that the backend is stuck in some kind of endless loop. Since
>> it's a production Debian server, the backend is not compiled with debugging
>> turned on. The best I can do is ltrace it, in
dle
8355 ?Ss 0:01 \_ postgres: cms cms 10.0.0.5(59188) idle
13504 ?Ss 0:05 \_ postgres: cms cms 10.0.0.5(35244) idle
17568 ?Ss 0:01 \_ postgres: cms cms 10.0.0.5(50414) idle
17615 ? Ss 0:02 \_ postgres: cms cms 10.0.0.5(42313) idle
176
puzzled by option number 2. Is there even a single
>use case for that?
I can't imagine one, and (in this thread at least) noone has demonstrated
such; Tom hinted at one, but he didn't elaborate.
--
Sincerely,
Stephen R. van den Berg.
"Very funny, Mr. Scott. Now beam d
s more than 20%, store uncompressed otherwise.
Sc. Check if the compression saves more than 20%, store uncompressed otherwise.
Sd. Check if the compression saves more than 20%, store uncompressed otherwise.
For Sb, Sc and Sd we should probably only check the first 256KB or so to
determine the expe
A.M. wrote:
>On Jan 5, 2009, at 1:16 PM, Stephen R. van den Berg wrote:
>>Upon reading the DFSG, it seems you have a point...
>>However...
>>QuickLZ is dual licensed:
>>a. Royalty-free-perpetuous-use as part of the PostgreSQL backend or
>> any derived works of P
be used under GPL.
In essence, it would be kind of a GPL license on steroids; it grants
Berkeley-style rights as long as the source is part of PostgreSQL (or a
derived work thereof), and it falls back to GPL if extracted.
--
Sincerely,
Stephen R. van den Berg.
"Well, if we'r
being distributed alongside with."
This should allow commercial reuse in derived products without undesirable
sideeffects.
--
Sincerely,
Stephen R. van den Berg.
"Well, if we're going to make a party of it, let's nibble Nobby's nuts!"
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
le to have a plugin facility?
>I guess the most likely candidate is the LZJB mechanism in ZFS which is
>CDDL licensed.
The most likely candidate for a speedy algorithm seems QuickLZ, the author
is willing to accomodate the licensing.
--
Sincerely,
Stephen R. van den Berg.
Cli
th PostgreSQL. Since I have exclusive copyright of QuickLZ any
> construction is possible.
>
> Greetings,
>
> Lasse Reinhold
> Developer
> http://www.quicklz.com/
> l...@quicklz.com
>
> On Sat Jan 3 15:46 , 'Stephen R. van den Berg' sent:
>
> PostgreSQL is the
, so it'd make sense to provide something similar
to the DBA.
--
Sincerely,
Stephen R. van den Berg.
Expect the unexpected!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
>On Fri, Jan 2, 2009 at 3:23 PM, Stephen R. van den Berg wrote:
>> Three things:
>> a. Shouldn't it in theory be possible to have a decompression algorithm
>> which is IO-bound because it decompresses faster than the disk can
>> supply the da
ns which would prevent me from
changing the algorithm to something more efficient (read: IO-bound)?
--
Sincerely,
Stephen R. van den Berg.
"Always remember that you are unique. Just like everyone else."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
e to require compressibility instead?
--
Sincerely,
Stephen R. van den Berg.
"Always remember that you are unique. Just like everyone else."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The other day I bumped into some ideas about lockfree hashtables.
Are these of any use in PostgreSQL?
http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html
http://video.google.com/videoplay?docid=2139967204534450862
--
Sincerely,
Stephen R. van den Berg.
"I hate sp
en and egg problem, by simply creating the
sample DB first, it creates the opportunity to gradually convert all examples
in the manual to use the sample DB (and patch the sample DB in the process to
be populated with the proper tables/functions to actually be useful in
the required examples).
--
Sincerel
Tom Lane wrote:
>"Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
>> What about simply closing the filedescriptor upon discovering a
>> non-empty sendbuffer upon timeout/querycancel?
>So in other words, convert any network glitch, no matter how small,
>i
buffer is full.
>Yeah, I've already explained those difficulties. I was hoping that
>discussion might generate ideas on how to deal with them.
What about simply closing the filedescriptor upon discovering a
non-empty sendbuffer upon timeout/querycancel?
--
Sincerely,
Steph
but please do not use that as justification for using -m.
That would be equally silly as abbreviating "number of workers" to -n.
--
Sincerely,
Stephen R. van den Berg.
Experience is something you don't get until just after you need it.
--
Sent via pgsql-hackers mailing
Tom Lane wrote:
>"Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
>> Intervals are a scalar, not an addition of assorted values, alternating signs
>> between fields would be wrong.
>Sorry, you're the one who's wrong on that. We've treated int
0'
Intervals are a scalar, not an addition of assorted values, alternating signs
between fields would be wrong.
--
Sincerely,
Stephen R. van den Berg.
He did a quarter of the work in *half* the time!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e only thing you can reasonably count on is that
the WHERE clause is evaluated before the SELECT-result-rows and the
ORDER BY clause (in any SQL database).
You cannot depend on any left to right order, and you cannot depend on
ORDER BY being evaluated after the SELECT-result-rows.
--
Sincerely,
the server generates an appropriate error
message when someone attempts to do this?
--
Sincerely,
Stephen R. van den Berg.
"Having a non-smoking section in a restaurant is like
having a non-peeing section in a pool."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
ll. And it affects
I wanted to have this many times, actually I considered it a bug that
it didn't report the position.
--
Sincerely,
Stephen R. van den Berg.
Several ways to kill a programmer: kill -15, fair trial; kill -1, death by
hanging; kill -2, suicide; kill -3, eut
serves those for the implementation (the compiler and lib).
Either use the old global name or something like newMode_result.
--
Sincerely,
Stephen R. van den Berg.
Several ways to kill a programmer: kill -15, fair trial; kill -1, death by
hanging; kill -2, suicide; kill -3, euthanasia; kill -9, exec
eate a function newNode() which is declared as inline, which
basically gives you the same code as under (a).
--
Sincerely,
Stephen R. van den Berg.
"Good moaning!"
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ndeed).
It seems a like a natural solution to marry the two.
--
Sincerely,
Stephen R. van den Berg.
E-mails should be like a lady's skirt:
Long enough to cover the subject, and short enough to be interesting.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
a
>workaround, since we'll need to keep it around forever? (We have special
>handling of a few other parameters already, so maybe not?)
You only need to keep the runtimeparameter for as long as you don't bump
the protocol version.
Then again, runtimeparameters are cheap.
--
Sincerely
plainkey,hmaccoded
which the client can then chose from.
I'd prefer b over a.
--
Sincerely,
Stephen R. van den Berg.
"And now for something *completely* different!"
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Stephen R. van den Berg wrote:
>A.M. wrote:
>>Anyway, what does "The driver beats libpq in speed by about 62%" mean?
>I.e. speed comparison is 762/483 = 1.63 -> 63% faster.
After some tuning on the libpq side, I can say that:
If libpq is called using a cursor and fet
Stephen R. van den Berg wrote:
>The fetch_row() function actually returns an array for each row, where
>the individual columns are already parsed and converted into the native
>Pike formats for handling.
A typical (low level) usage sequence in Pike looks like this:
object db;
ady parsed and converted into the native
Pike formats for handling.
--
Sincerely,
Stephen R. van den Berg.
"People who think they know everything are annoying to those of us who do."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Stephen R. van den Berg.
"Even if man could understand women, he still wouldn't believe it."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nything in the JDBC driver
I'll relicense it under a BSD license, so you can use it.
Watch this space.
--
Sincerely,
Stephen R. van den Berg.
"Even if man could understand women, he still wouldn't believe it."
--
Sent via pgsql-hackers mailing list (pgsql-h
Dave Cramer wrote:
>On 27-Jul-08, at 3:00 PM, Stephen R. van den Berg wrote:
>>Stephen R. van den Berg wrote:
>>The driver beats libpq in speed by about 62%.
>>Anyone interested in taking a peek at the (GPL copyright) driver, I
>>temporarily put up a small package
I replied to this post, yesterday. Yet I don't see my reply appear,
could it have been caught in a spamfilter or something?
--
Sincerely,
Stephen R. van den Berg.
"Even if man could understand women, he still wouldn't believe it."
--
Sent via pgsql-hackers
Stephen R. van den Berg wrote:
>My Pike drivers now support multiple simultaneous portals and
>automatic streaming by presending overlapping Execute statements with
>a dynamically adapted fetchlimit calculated per select as the query
>progresses.
They also support COPY now.
The
fy it regardless of what the COPY command says?
--
Sincerely,
Stephen R. van den Berg.
In this signature, the concluding three words `were left out'.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
ctice today.
My Pike drivers now support multiple simultaneous portals and
automatic streaming by presending overlapping Execute statements with
a dynamically adapted fetchlimit calculated per select as the query
progresses.
The only support still lacking is COPY.
--
Sincerely,
Stephen R.
Tom Lane wrote:
>"Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
>> Then, from a client perspective, there is no use at all, because the
>> client can actually pause reading the results at any time it wants,
>> when it wants to avoid storing all of
On Thu, Jul 10, 2008 at 05:31, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
>> I was wondering, if there is any real advantage to actually specify say
>> 64 for the maxrows parameter to the Execute message
s with the Execute maxrows parameter.
--
Sincerely,
Stephen R. van den Berg.
Limited offer: Pacemakers, with a unique life-time warranty
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f the connection?
Or can I leave them hardcoded in the driver?
--
Sincerely,
Stephen R. van den Berg.
A truly wise man never plays leapfrog with a unicorn.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
What's the deal with this type? Is it used internally?
It's the only type that seems to have anything meaningfull in
typdefaultbin and typdefault columns in pg_type.
--
Sincerely,
Stephen R. van den Berg.
WARNING: Do not look into laser with remaining eye
--
Sent via pgs
call libpq several times, and get a few rows at a time, which
are read from the DB-stream when needed.
--
Sincerely,
Stephen R. van den Berg.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
ses (like all pages required for
>everything else happened to equal 4 Gbytes near exactly).
There is always only so much of 1st level and 2nd level cache; for those
the savings might well make a difference, even on multigigabyte
databases.
--
Sincerely,
Stephen R. van den Berg.
L
ives-to-a-text-editor have to work within that reality.
I think everyone is aware of that.
--
Sincerely,
Stephen R. van den Berg.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ation elegant.
IMHO Greg's response is the most comprehensive and well-thought-through
contribution in the whole GUC thread.
--
Sincerely,
Stephen R. van den Berg.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
as in:
SELECT * FROM computers
ORDER BY HIGHEST(main_memory) DESC, HIGHEST(cpu_speed) DESC;
--
Sincerely, [EMAIL
PROTECTED]
Stephen R. van den Berg.
"Sleep: A completely inadequate substitute for caffeine."
--
Sent via
ter than b, is it?
--
Sincerely, [EMAIL
PROTECTED]
Stephen R. van den Berg.
"Technology is stuff that doesn't work yet." -- Bran Ferren
"We no longer think of chairs as technology." -- Douglas Adams
--
Sent via pgsql-hackers maili
75 matches
Mail list logo
