No.
I think one option is fix it in the cvs client. There
are options there to do it if you use cvsnt.
FWIW, if I built off the snapshot tarballs things work, since they have
unix linefeeds.
//Magnus
On Tue, Feb 20, 2007 at 05:11:41PM -0500, Bruce Momjian wrote:
Was this problem addressed?
Do 97% of transactions commit because Oracle has slow rollbacks and
developers are working around that performance issue, or because they
really commit?
I have watched several developers that would prefer to issue numerous
selects to verify things like foreign keys in the application
Hi,
Tom Lane wrote:
You mean four different object types. I'm not totally clear on bison's
scaling behavior relative to the number of productions
You really want to trade parser performance (which is *very*
implementation specific) for ease of use?
Bison generates a LALR [1] parser, which
On Mon, Feb 19, 2007 at 11:18:36AM -0500, Tom Lane wrote:
Magnus, I'd suggest reverting whatever you did to your MSVC script,
so we'll find out the next time someone makes this mistake...
Reverted. I left the part in genbki.pl in there, because that's a plain
bug that was exposed by this,
Hi there,
We have several patches already discussed in -hackers and waiting for
decision. Current versions adapted for HEAD are available:
1. built-in FTS http://www.sigaev.ru/misc/tsearch_core-0.35.gz
Documentation is available http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
as a separate book,
Markus Schiltknecht wrote:
Hi,
Tom Lane wrote:
You mean four different object types. I'm not totally clear on bison's
scaling behavior relative to the number of productions
You really want to trade parser performance (which is *very*
implementation specific) for ease of use?
Bison
Phil Currier escribió:
Inspired by this thread [1], and in particular by the idea of storing
three numbers (permanent ID, on-disk storage position, display
position) for each column, I spent a little time messing around with a
prototype implementation of column storage positions to see what
Theo Schlossnagle wrote:
On Feb 20, 2007, at 1:40 PM, Tom Lane wrote:
RPK [EMAIL PROTECTED] writes:
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced
database
(PostgreSQL, as they say), must have an
Nikolay Samokhvalov wrote:
Now we have --with-libxml (and USE_LIBXML constant for #ifdef-s), what
is not absolutely right: XML support is smth that is more general than
using libxml2 library. E.g., some SQL/XML publishing functions (such
as XMLPI) do not deal with libxml2.
Also, in the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
I looked at the diff file and the major change in gram.y is the creation
of a new
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. drop table deletes datafiles at commit time, and not during vacuum.
Not to mention the likenesses of CLUSTER and TRUNCATE,
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort the columns to the most
efficient order; ALTER TABLE ADD
Hi,
Florian G. Pflug wrote:
According to http://en.wikipedia.org/wiki/LR_parser processing one
token in any LR(1) parser in the worst case needs to
a) Do a lookup in the action table with the current (state, token) pair
b) Do a lookup in the goto table with a (state, rule) pair.
c) Push one
Nikolay Samokhvalov wrote:
Also, in the future more non-libxml functionality could be added to
XML support (well, Peter's recent SQL-to-XML mapping functions
prove it).
But note that those are not controlled by the --with-libxml switch.
--
Peter Eisentraut
Florian G. Pflug [EMAIL PROTECTED] writes:
Markus Schiltknecht wrote:
I didn't find hard facts about runtime complexity of LALR,
though (pointers are very welcome).
a) and b) should be O(1). Processing one token pushes at most one state
onto the stack, so overall no more than N stats can be
Markus Schiltknecht wrote:
Hi,
I recall having read something about rewriting the parser. Together
with Tom being worried about parser performance and knowing GCC has
switched to a hand written parser some time ago, I suspected bison to
be slow. That's why I've asked.
This has little to
Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort the columns to the most
efficient
Markus Schiltknecht wrote:
Are there any ongoing efforts to rewrite the parser (i.e. using
another algorithm, like a recursive descent parser)?
Why would you want to do that?
I recall having read something about rewriting the parser. Together with
Tom being worried about parser performance
Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort the columns to the most
efficient order;
Alvaro Herrera wrote:
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. drop table deletes datafiles at commit time, and not during vacuum.
Not to mention the likenesses
Florian G. Pflug [EMAIL PROTECTED] writes:
Markus Schiltknecht wrote:
Are there any ongoing efforts to rewrite the parser (i.e. using
another algorithm, like a recursive descent parser)?
Why would you want to do that?
Last, but not least, the C and C++ syntax is basically set in stone - At
As was discussed in several threads, I'd handed over the
responsibility of hierarchical queries to Greg Stark several weeks
ago. He posted a preliminary patch which I don't believe anyone
looked at. For 8.3's sake, I wanted to make sure we get the status of
this out on the table so there won't
Bruce Momjian escribió:
Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort the
On 2/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Keep in mind we have a patch in process to reduce the varlena length and
reduce alignment requirements, so once that is in, reordering columns
will not be as important.
Well, as I understand it, that patch isn't really addressing the same
Phil Currier wrote:
On 2/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Keep in mind we have a patch in process to reduce the varlena length and
reduce alignment requirements, so once that is in, reordering columns
will not be as important.
Well, as I understand it, that patch isn't
Alvaro Herrera wrote:
Bruce Momjian escribi?:
Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you
On Wed, Feb 21, 2007 at 03:59:12PM +0100, Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to chance to optimize the ordering, you might
throw away changes
Jan Wieck wrote:
On 1/25/2007 7:33 PM, Tom Lane wrote:
1 fires always
0 fires never
N fires in Normal mode
R fires in Replica mode
other letters available for other future mode values?
If you consistently think of
Benjamin Arai wrote:
Is there a way to give priorities to queries or users? Something similar to
NICE in Linux. My goal is to give the updating (backend) application a very
low priority and give the web application a high priority to avoid
disturbing the user experience.
Thanks in
Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to chance to optimize the ordering, you might
throw away changes that the admin has done on purpose. The same
On Friday 09 February 2007, Jan Wieck wrote:
I am not sure, I would have to look at what exactly that hook provides.
The key to a Lamport timestamp is that it is advancing it commit order
(plus some other things ... of course). If the hook can guarantee that
the calls are made always in commit
On 2/21/07, Martijn van Oosterhout kleptog@svana.org wrote:
On Wed, Feb 21, 2007 at 03:59:12PM +0100, Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to
Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 03:59:12PM +0100, Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to chance to optimize the ordering, you
Andrew Dunstan wrote:
Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to chance to optimize the ordering, you might
throw away changes that the admin has done
On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
Well, for two reasons:
1) If you have a table with one very-frequently-accessed varchar()
column and several not-frequently-accessed int columns, it might
actually make sense to put the varchar column first. The system won't
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort
On Mon, 2007-02-12 at 09:24 +0530, Pavan Deolasee wrote:
On 2/12/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-11 kell 12:35, kirjutas Tom
Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
What if we
On 2/21/07, Martijn van Oosterhout kleptog@svana.org wrote:
don't see any good way to perform an upgrade between PG versions
without rewriting each table's data. Maybe most people aren't doing
upgrades like this right now, but it seems like it will only become
more common in the future. In
Simon Riggs wrote:
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you
On 2/21/07, Simon Riggs [EMAIL PROTECTED] wrote:
I very much like Hannu's idea, but it does present some issues.
I too liked Hannu's idea initially, but Tom raised a valid concern
that it does not address the basic issue of root tuples. According
to the idea, a DEAD root tuple can be used
On Wed, 2007-02-21 at 13:16 -0500, Andrew Dunstan wrote:
Simon Riggs wrote:
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible
On Thu, 2007-02-22 at 00:00 +0530, Pavan Deolasee wrote:
On 2/21/07, Simon Riggs [EMAIL PROTECTED] wrote:
I very much like Hannu's idea, but it does present some
issues.
I too liked Hannu's idea initially, but Tom raised a valid concern
that it does not
On Tue, 2007-02-20 at 09:48 +0200, Hannu Krosing wrote:
I'm not sure about the we are more concerned about the large tables
part. I see it more as a device for high-update tables. This may not
always be the same as large, so there should be some fallbacks for
case where you can't get the
Phil Currier wrote:
On 2/21/07, Martijn van Oosterhout kleptog@svana.org wrote:
don't see any good way to perform an upgrade between PG versions
without rewriting each table's data. Maybe most people aren't doing
upgrades like this right now, but it seems like it will only become
more
On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
Well, for two reasons:
1) If you have a table with one very-frequently-accessed varchar()
column and several not-frequently-accessed int columns, it might
actually make
Simon Riggs wrote:
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create
Simon Riggs wrote:
I agree with comments here about the multiple orderings being a horrible
source of bugs, as well as lots of coding even to make it happen at all
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00859.php
I thought we were going with this later proposal of Tom's
Stephan Szabo escribió:
On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
Well, for two reasons:
1) If you have a table with one very-frequently-accessed varchar()
column and several not-frequently-accessed int
Andrew Dunstan escribió:
Simon Riggs wrote:
I agree with comments here about the multiple orderings being a horrible
source of bugs, as well as lots of coding even to make it happen at all
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00859.php
I thought we were going with this
Florian G. Pflug [EMAIL PROTECTED] writes:
Why would a pg_migrator style upgrade use pg_dump at all? I assumed it
would rather copy the verbatim data from the old to the new catalog,
only changing it if the layout of the tables in pg_catalog actually changed.
The way pg_migrator works is
Alvaro Herrera wrote:
I haven't understood Alvaro to suggest not keeping 3 numbers.
Right, I'm not advocating not doing that -- I'm just saying that the
first step to that could be decoupling physical position with attr id
:-) Logical column ordering (the order in which SELECT *
Jonah H. Harris [EMAIL PROTECTED] writes:
As was discussed in several threads, I'd handed over the
responsibility of hierarchical queries to Greg Stark several weeks
ago. He posted a preliminary patch which I don't believe anyone
looked at. For 8.3's sake, I wanted to make sure we get the
Hello
yesterday I sent posted bug, bud it hangs because I am not member of
psql-bug mailing list. Can somebody look to queue?
Thank You
Pavel Stehule
_
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
On Wed, 21 Feb 2007, Jonah H. Harris wrote:
As was discussed in several threads, I'd handed over the
responsibility of hierarchical queries to Greg Stark several weeks
ago. He posted a preliminary patch which I don't believe anyone
looked at. For 8.3's sake, I wanted to make sure we get the
On 2/21/07, Gregory Stark [EMAIL PROTECTED] wrote:
So yes, there would be a use case for specifying the physical column layout
when pg_migrator is doing the pg_dump/restore. But pg_migrator could probably
just update the physical column numbers itself. It's not like updating system
catalog
Phil Currier escribió:
On 2/21/07, Gregory Stark [EMAIL PROTECTED] wrote:
So yes, there would be a use case for specifying the physical column layout
when pg_migrator is doing the pg_dump/restore. But pg_migrator could
probably
just update the physical column numbers itself. It's not like
On Wed, 21 Feb 2007, Alvaro Herrera wrote:
Stephan Szabo escribi?:
On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
Well, for two reasons:
1) If you have a table with one very-frequently-accessed varchar()
Ok, scratch that :-) Another round of braindumping below.
Launcher starts one worker in each database. This worker is not going
to do vacuum work, just report how much vacuum effort is needed in the
database. Vacuum effort is measured as the total number of pages in
need of vacuum, being the
Stephan Szabo wrote:
What I was mentioning was that I was pretty sure that there
was a message with someone saying that they actually tried something that
did this and that they found left-most varchar access was slightly slower
after the reordering although general access was faster. I
Stephan Szabo wrote:
On Wed, 21 Feb 2007, Alvaro Herrera wrote:
Did I miss something in what you were trying to say? I assume you must
already know this.
I think so. What I was mentioning was that I was pretty sure that there
was a message with someone saying that they actually tried
On Feb 18, 9:35 am, [EMAIL PROTECTED] (Tom Lane) wrote:
Russell Smith [EMAIL PROTECTED] writes:
If you replan and immutable function, aren't you possibly messing up a
functional index that is using the old function. Hey, if you change an
immutable function that has an index, you are in
Florian G. Pflug wrote:
BTW, this is a good case for why the storage order should - directly or
indirectly - be tweakable. You can either optimize for space, and _then_
for speed - which is what the OP did I think - or first for speed, and
then for space. If the dba cannot choose the
Andrew Dunstan [EMAIL PROTECTED] writes:
I would want to see this very carefully instrumented. Assuming we are putting
all fixed size objects at the front, which seems like the best arrangement,
then the position of every fixed field and the fixed portion of the position
of
every varlena
Alvaro Herrera wrote:
Ok, scratch that :-) Another round of braindumping below.
I still think this is solution in search of a problem. The main problem
we have right now is that hot tables can be starved from vacuum. Most
of this proposal doesn't touch that. I would like to see that
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Stark and Matthew O'Connor say that we're misdirected in having
more than one worker per tablespace. I say we're not :-)
I did say that. But your comment about using a high cost_delay was fairly
convincing too. It would be a simpler design and
Gavin Sherry [EMAIL PROTECTED] writes:
The WITH support seems okay. I guess I'd thought it might be represented
different internally (not a sub query) but the approach Greg has taken is
probably more straight forward (in that you get a lot of proven code for
free). It should work fine for
Ron Mayer expressed the thought that we're complicating needlessly the
UI for vacuum_delay, naptime, etc. He proposes that instead of having
cost_delay etc, we have a mbytes_per_second parameter of some sort.
This strikes me a good idea, but I think we could make that after this
proposal is
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I would want to see this very carefully instrumented. Assuming we are putting
all fixed size objects at the front, which seems like the best arrangement,
then the position of every fixed field and the fixed portion of the
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I would want to see this very carefully instrumented. Assuming we are
putting
all fixed size objects at the front, which seems like the best arrangement,
then the position of every
Anyone making those kind of decisions probably wants a generic
connection is encrypted flag. It could be true if a GSSAPI
connection has negotiated use of a security layer.
Of course I don't have my GSSAPI patches working as well as the SASL
ones were yet, and I haven't started on adding
On Wed, 21 Feb 2007, Gregory Stark wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
The WITH support seems okay. I guess I'd thought it might be represented
different internally (not a sub query) but the approach Greg has taken is
probably more straight forward (in that you get a lot of
Gavin Sherry [EMAIL PROTECTED] writes:
Can you elaborate on the 'two different sets of parameters' bit? I'm still
without coffee.
The spec allows for arbitrarily complex recursive query structures. Including
mutually recursive queries, and even non-linearly recursive queries. I found
grokking
On Thu, 22 Feb 2007, Gregory Stark wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Can you elaborate on the 'two different sets of parameters' bit? I'm still
without coffee.
The spec allows for arbitrarily complex recursive query structures. Including
mutually recursive queries, and even
On Wed, Feb 21, 2007 at 08:33:10PM +0100, Florian G. Pflug wrote:
Simon Riggs wrote:
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
On 2/21/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible
elein wrote:
The storage order is orthogonal to the display order. display order can be
handled
in attnum and the new storage order can be the new column.
If you review the earlier discussion you will see that it is proposed
(by Tom) to have 3 numbers (i.e. 2 new cols): an immutable
Are there any plans to move to another SCMS in the future? I am curious, I
guess.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Monday 19 February 2007 22:59, Greg Smith wrote:
I have a WIP patch that adds the main detail I have found I need to
properly tune checkpoint and background writer activity. I think it's
almost ready to submit (you can see the current patch against 8.2 at
Andrew Dunstan [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Right, I'm not advocating not doing that -- I'm just saying that the
first step to that could be decoupling physical position with attr id
:-) Logical column ordering (the order in which SELECT * expands to)
seems to me to be a
Is there a reason why the DATE type does not support infinity something like
the DATE type?
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Warren Turkal [EMAIL PROTECTED] writes:
Are there any plans to move to another SCMS in the future?
Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
In that proposed syntax, I would drop all =, ,, (, and ). They
don't seem necessary and they are untypical for SQL commands. I'd
compare with
Joshua D. Drake wrote:
This is like the third time we have been around this problem. The
syntax is clear and reasonable imo.
But others have differing opinions.
Can we stop arguing about it and just include? If there are specific
issues beyond syntax that is one
thing, but that this point
Warren Turkal [EMAIL PROTECTED] writes:
Is there a reason why the DATE type does not support infinity
Nobody got round to it. I believe it's listed in the TODO file ...
regards, tom lane
---(end of broadcast)---
TIP 1: if
On Thu, 22 Feb 2007, Peter Eisentraut wrote:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
In that proposed syntax, I would drop all =, ,, (, and ). They
don't seem necessary and they are
On Thursday 22 February 2007 00:20, Tom Lane wrote:
Nobody got round to it. I believe it's listed in the TODO file ...
It's not at [1]. Should someone add it to the TODO?
[1]http://www.postgresql.org/docs/faqs.TODO.html
wt
--
Warren Turkal (w00t)
---(end of
On Thursday 22 February 2007 00:05, Tom Lane wrote:
Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the pain
of converting.
Some of the other
Warren Turkal [EMAIL PROTECTED] writes:
On Thursday 22 February 2007 00:20, Tom Lane wrote:
Nobody got round to it. I believe it's listed in the TODO file ...
It's not at [1]. Should someone add it to the TODO?
I see
* Dates and Times
o Allow infinite dates and intervals just like
Warren Turkal [EMAIL PROTECTED] writes:
On Thursday 22 February 2007 00:05, Tom Lane wrote:
Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the pain
On Thu, 22 Feb 2007, Warren Turkal wrote:
On Thursday 22 February 2007 00:20, Tom Lane wrote:
Nobody got round to it. I believe it's listed in the TODO file ...
It's not at [1]. Should someone add it to the TODO?
[1]http://www.postgresql.org/docs/faqs.TODO.html
Yes it is.
Allow infinite
On Thursday 22 February 2007 00:42, you wrote:
I think you just made my point for me.
I wasn't trying to convince so much as get an opinion.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
90 matches
Mail list logo
