Kenneth Marshall wrote:
We use DSPAM as one of our anti-spam options. Its UPDATE pattern is to
increment a spam counter or a not-spam counter while keeping the user and
token information the same. This would benefit from this optimization.
Currently we are forced to use MySQL with MyISM tables to
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several FTS
configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
in GUC variable tsearch_conf_name. If it's not defined, then FTS
config
Oleg Bartunov wrote:
On Fri, 23 Mar 2007, Florian G. Pflug wrote:
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several
FTS configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration c
Pavan Deolasee wrote:
On 3/23/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Why exactly can't a SERIALIZABLE transaction use the index it created
itself? If you add a pointer to the root of all HOT update chains where
either the HEAD is alive, or some tuple is visible to the
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several FTS
configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
in GUC variable tsearch_conf_name. If it's not defined, then FTS
config
Pavan Deolasee wrote:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data, but I don't think anybody is going to
complain about that restriction. Anyone?
Oh, I did not se
Pavan Deolasee wrote:
On 3/21/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 3/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> It seems much simpler to me do something like this. But important
> question is whether the restriction that CREATE INDEX can not
> be run in a transaction block i
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Here is a paper about portable userspace threads that I just googled.
http://www.gnu.org/software/pth/rse-pmt.ps
I'm not impressed --- the list of unsolved problems is a bit too long.
One that seems a showsto
Gregory Stark wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Since context switching would occur only at two well-defined places
(Some return_next_row function that PLs call when a SFR returns a row,
and in the executor if no more previously returned rows from that S
Andrew Dunstan wrote:
Florian G. Pflug wrote:
Just a thought - I believe that there are portable user-space thread
implementations that contain little or no machine-specific code. What
if postgres used one of those to switch from the PL into the executor
and back after, say, 1000 rows were
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Yes, more or less. That's what made me think of it.
OTOH, before we rush out and do it someone needs to show that it's a net win. I
agree with Tom that making tuplestore faster would probably be a much better
investment of time.
Mickael DELOISON wrote:
For a programming language, as it would be for GSoC, it has to be
realized in three month and I believe the utility has to be
cross-platform (anyway I want it to be). So I think Java would be
good. I am very used to Java and Swing programming. What do you think
about that
Robert Treat wrote:
On Friday 16 March 2007 10:45, Teodor Sigaev wrote:
I don't see how the proposal is going to solve that type of problem, but
maybe I am overlooking something?
The same way as other system tables objects, they don't dump, they don't
restore. In 8.3, seems, API to index AM wil
Oleg Bartunov wrote:
On Fri, 16 Mar 2007, Joshua D. Drake wrote:
One a related note - will to_tsvector and to_tsquery be renamed to
something like ft_parse_text() and ft_parse_query() if tsearch2 goes
Furthering this... perhaps even:
ft_search()
ft_query()
ts_ means Text Search, I don't
Teodor Sigaev wrote:
CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
Fulltext_ops opclass parses the document similarly to_tsvector nad
stores lexemes in gin index. It's a full equalent of
CREATE INDEX ... ( to_tsvector( textcolumn ) )
And, let we define operation text @
Heikki Linnakangas wrote:
There's a third related term in use as well. When you issue CLUSTER, the
table will be clustered on an index. And that index is then the "index
the table is clustered on". That's a bit cumbersome but that's the
terminology we're using at the moment. Maybe we should to
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
We wouldn't clean up tuples that are visible to a transaction, but if
you have one long-running transaction like pg_dump in a database with
otherwise short transaction, you'll have a lot of tuples that are not
vacuumable because of
Heikki Linnakangas wrote:
The implementation problem is that we don't have a global view of all
snapshots in the system. If we solve that, we can be more aggressive
with vacuuming in presence of long-running transactions. It's not an
easy problem, we don't want to add a lot of accounting overhe
Gaetano Mendola wrote:
Martijn van Oosterhout wrote:
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x => 8.2.3 and I had on
first hour of service up
lot of queries "blocked" due to this, consider in my case I have on v_ta
mi
Heikki Linnakangas wrote:
Csaba Nagy wrote:
On Fri, 2007-03-09 at 14:00, Alvaro Herrera wrote:
But I'm not really seeing the problem here. Why isn't Csaba's problem
fixed by the fact that HOT reduces the number of dead tuples in the
first place? If it does, then he no longer needs the CLUSTER
Martijn van Oosterhout wrote:
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x => 8.2.3 and I had on
first hour of service up
lot of queries "blocked" due to this, consider in my case I have on v_ta
milions of records and usu
Martijn van Oosterhout wrote:
On Wed, Mar 07, 2007 at 02:43:39AM +1030, Shane Ambler wrote:
I think a way can be devised to maintain the primary key and unique
constraints.
If a search is done on the parent table, the planner knows to rewrite
the query as a union (or union all) of all child tab
Jim Nasby wrote:
On Mar 1, 2007, at 8:45 AM, Florian G. Pflug wrote:
Another possibility would be to move this setting into the
recovery.conf. The problems
with this approach is that the recovery.conf file is deleted after the
information
it contains is incorporated into pg_control. Thus, the
Simon Riggs wrote:
On Mon, 2007-03-05 at 14:41 -0500, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
Itakgaki-san and I were discussing in January the idea of cache-looping,
whereby a process begins to reuse its own buffers in a ring of ~32
buffers. When we cycle back round, if usage
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit
would be calculated as
GetOldestXmin() - vacuum_freeze_limit
We already have that. It's called vacuum_freeze_min_age, and the default
is 100 million transactions.
II
Tom Lane wrote:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
This is a stand-alone patch for aggressive freezing. I'll propose
to use OldestXmin instead of FreezeLimit as the freeze threshold
in the circumstances below:
I think it's a really bad idea to freeze that aggressively under any
circu
Bruno Wolff III wrote:
On Thu, Mar 01, 2007 at 11:26:23 +0100,
"Florian G. Pflug" <[EMAIL PROTECTED]> wrote:
But just postponing nextval() until after the uniqueness checks
only decreases the *probability* of non-monotonic values, and
*does not* preven them. Consindert two
Gregory Stark wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1;
This allow to make an insert, and if the key is already there to modify the
value depending on the current one.
May this could be
Andrew Dunstan wrote:
Jonathan Scher wrote:
Hello,
I'd like to work on TODO item:
> Add REPLACE or UPSERT command that does UPDATE, or on failure, INSERT
could you please tell me if I'm going in the right way?
There are some different syntaxes possible, but MySQL has an
interesting one here:
Hi
I've updated (or rather rewritten) my proposal for implementing
read-onyl queries on PITR slaves as a "Summer of Code 2007" project.
I've added are more details description of how I plan implement
a read-only mode suitable for PITR slaves, and put in a few
possible enhancements to the "Big, G
Zoltan Boszormenyi wrote:
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
cannot skip a value in the sequence, the strict mono
Merlin Moncure wrote:
getting back on topic (ahem), florian: are you comfortable going ahead
with this? is there anything you need help with?
I'm currently updating my proposal, trying to incorporate the points
people brought up in this thread.
I realized that trying to use the same kind of "
David Fetter wrote:
On Mon, Feb 26, 2007 at 11:14:01PM -0500, Tom Lane wrote:
Rusty Conover <[EMAIL PROTECTED]> writes:
Or allow delete and update to be used in sub-queries?
That's been discussed but the implementation effort seems far from
trivial. One big problem is that a sub-query can no
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
My line of reasoning is that stopping wal replay at a arbitrary point,
and then starting a read-only transaction with an "empty snapshot" (meaning
that all exactly those transactions marked as comitted in t
Josh Berkus wrote:
People weren't very interested in having a read-only mode. I think it
would be a nice feature if it's not too complicated.
Actually, I think there's high demand for it off this list. Effectively it
would allow our "warm backup mode" to become a "hot backup mode". As SoC
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.
I've been browsing the postgres source-code for the last few days,
and came up with the follo
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.
You are discussing this on the wrong list.
So what list would be mo
Hi
I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.
I've been browsing the postgres source-code for the last few days,
and came up with the following plan for a implementation.
I'd be very interested in any f
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
I think you should increase pg_control version.
And the WAL page-header version, since this also changes WAL contents.
Here is an updated version. I've incremeted XLOG_PAGE_MAGIC and
PG_CONTROL_VERSION by one.
greetings, Florian Pfl
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Heikki Linnakangas wrote:
No you're right, it's related to the WAL undo stuff that was never
actually implemented. It's dead code.
Teodor Sigaev wrote:
Opps, sorry, I missed checkpoint keyword
Teodor Sigaev wrote:
What am I
Hi
After futher reading I fear I have to bother you with another question ;-)
There is a flag XLOG_NO_TRAN passed via the info parameter to XLogInsert.
Now, for example the following comment in clog.c
/*
* Write a TRUNCATE xlog record
*
* We must flush the xlog record to disk before returning
Heikki Linnakangas wrote:
No you're right, it's related to the WAL undo stuff that was never
actually implemented. It's dead code.
Teodor Sigaev wrote:
Opps, sorry, I missed checkpoint keyword
Teodor Sigaev wrote:
What am I missing?
Seems, it's about that
http://archives.postgresql.org/pg
Hi
I'm trying to gain a better understanding of how the postgres
xlog works - especially about the corner cases of wal replay.
One thing that I do not understand is what CheckPoint.undo is
used for. I grepped through the source, and only see very few
references to it, which either just print it,
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 somethin
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
Phil Currier wrote:
On 2/21/07, Martijn van Oosterhout 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 futu
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
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
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
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;
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 an
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 opt
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 generat
August Zajonc wrote:
Gregory Stark wrote:
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that cont
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
I'd suggest that the text is changed to something along the line of:
"database system was interrupted while in recovery at ...
If this has occurred more than once some data may be corrupted and
you may nee
Zeugswetter Andreas ADI SD wrote:
First we must run the query in serializable mode and replace the
snapshot with a synthetic one, which defines visibility at the
start
of the desired transaction
probably it is a good idea to take a lock on all tables involved to
avoid a vacuum to be started
Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
To get a flashback query, you "just" have to construct a snapshot from
that time and you are done. We don't store t
Hi
When postgres crashes during recovery, and is then restarted, it
says:
"database system was interrupted while in recovery at ...
This probably means that some data is corrupted and
you will have to use the last backup for recovery."
When I first read that message, I assumed that there are cas
Neil Conway wrote:
On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call. I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed.
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief <[EMAIL PROTECTED]> writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
ope
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief <[EMAIL PROTECTED]> writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb i
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief <[EMAIL PROTECTED]> writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down enough
--- no exceptions, no RTTI, no use of C++
Robert Treat wrote:
On Saturday 10 February 2007 13:59, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
I'd say we probably want to keep the tgargs info for at least a version
or two after changing the implementation. Getting rid of using the args
info sounds like a good idea.
We wh
Simon Riggs wrote:
My earlier thinking was that Oracle appears to be able to avoid locking
and my thought was that this was simply a rather dodgy interpretation of
the SQL Standard. Anyway, I'm not happy with simply forgetting the SHARE
lock; that clearly leads to invalid states in some cases, ev
Jochem van Dieten wrote:
On 2/1/07, Chris Dunlop wrote:
In maillist.postgres.dev, you wrote:
Rather than writing in-place, perhaps the SET ARCHIVE would
create a on-disk copy of the table.
Just like CLUSTER does now: create an on-disk copy first and swap the
relfilenodes of the files and flush
Csaba Nagy wrote:
The reason of the occasional orphan rows is not completely clear to me,
but it must be some kind of race condition while
inserting/deleting/?updating concurrently the parent/child tables.
I guess the following sequence would generate a orphaned row.
A: executes "insert into ta
elein wrote:
- Forwarded message from elein <[EMAIL PROTECTED]> -
Build error is:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels
-fno-strict-aliasing -g -Wno-error -L../../../../src/port
-Wl,-rpath,'/local/pgsql82/lib' preproc.o type.o ecpg.o ecpg_keywords.
Peter Eisentraut wrote:
I wrote:
We need to decide on how to handle encoding information embedded in
xml data that is passed through the client/server encoding
conversion.
Tangentially related, I'm currently experimenting with a setup that
stores all xml data in UTF-8 on the server, convertin
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Couldn't the server change the encoding declaration inside the xml to
the correct
one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the da
Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
Would this mean that if the client_encoding is for example latin1, and I
retrieve an xml document uploaded by a client with client_encoding utf-8
(and thus having encoding="c" in the xml tag), that I w
Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 12:42 schrieb Nikolay Samokhvalov:
On 1/15/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES (xmlparse(document '...'));
Assum
Michael Enke wrote:
This works for small amount of data. But for large amount of data
the join takes a lot of time.
It certainly is faster then anly algorithm that checks for duplicates
for each lines of copy input could ever be. Especially for joins, doing
them in one large batch allows you to
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently overflow/underflow
and not throw an error?
Silent underflow is fine with me; it's the norm in most all float
implementatio
Jim Nasby wrote:
I'm teaching a class this week and a student asked me about OIDs. He
related the story of how in Sybase, if you moved a database from one
server from another, permissions got all screwed up because user IDs no
longer matched. I explained that exposing something like an integer
Tom Lane wrote:
Martijn van Oosterhout writes:
The trigger never runs as the owner of the table AIUI, only ever as the
definer of the function or as session user.
Yeah. This might itself be seen as a bug: I think you could make a
reasonable case that the default behavior ought to be to run a
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
Joshua D. Drake wrote:
On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
Tom,
Let's go with the easy fix. With regular 1GB segment size, having a
few
empty files in the data directory isn't going to hurt anyone.
No, but it wi
Joshua D. Drake wrote:
On Sun, 2006-11-19 at 11:28 -0800, Josh Berkus wrote:
Tom,
Let's go with the easy fix. With regular 1GB segment size, having a few
empty files in the data directory isn't going to hurt anyone.
No, but it will confuse DBAs ("What the heck are all these 0B files?"). Maybe
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Clarify description of CIDR-address column of pg_hba.conf, to discourage
people from trying notations like '10.6/16', which is accepted but does
not mean what you probably think. Per example from Paul Forgey.
Isn't
Tom Lane wrote:
Bernd Helmle <[EMAIL PROTECTED]> writes:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do "cd". I'm inclined to go
with Bernd's suggestion to change the docs to match the code, but does
anyone have a contrary opi
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
It looks like it should work to have just one polymorphic aggregate
definition, eg, array_accum(anyelement) returns anyarray.
I was hoping to do that, but since it's an aggregate the ffunc format
Jim C. Nasby wrote:
On Thu, Sep 28, 2006 at 03:07:39PM -0700, David Wheeler wrote:
PostgreSQLers,
I just ran into an issue where a client thought that autovacuum was
running but it wasn't. This is because it's not fatal when autovacuum
is on but stats_start_collector and/or stats_row_level
[EMAIL PROTECTED] wrote:
This is what I mean by after thought. PostgreSQL is designed for
32-bit processors. Which is fine. I'm not complaining. The question
was whether there is an interest in pursuing 64-bit specific
optimizations. In the PostgreSQL code, a quick check points me only to
"has lo
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
Revised patch enclosed, now believed to be production ready. This
implements regular log switching using the archive_timeout GUC.
Further patch enclosed implementing these changes plus the record type
version of pg_xlogfile_name_offset()
Peter Eisentraut wrote:
Arturo Pérez wrote:
The DBA therefore pokes the
right information into
the planner's statistical tables (or, perhaps, a more human-
manageable one that gets
"compiled" into the planner's stats).
I think we're perfectly capable of producing a system that can collect
the
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Image a complex, autogenerated query with looks something like this
select
from t1
join t2 on ...
join t3 on ...
join t4 on ...
...
...
where
.
This big, complicated expression looks different for e
Tom Lane wrote:
Martijn van Oosterhout writes:
ISTM theat the easiest way would be to introduce a sort of predicate
like so:
SELECT * FROM foo, bar WHERE pg_selectivity(foo.a = bar.a, 0.1);
The one saving grace of Florian's proposal was that you could go hack
the statistics *without* chang
Hi
Since the discussion about how to force a specific plan has
come up, I though I'd post an idea I had for this a while ago.
It's not reall well though out yet, but anyway.
When the topic of optimizer hints comes up, people often suggest
that there should be a way to force postgres to use a cer
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap algorit
Tom Lane wrote:
Rod Taylor <[EMAIL PROTECTED]> writes:
A simple way of doing this might be to use a minimum cost number?
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify "0"
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
be no need to roun
Tom Lane wrote:
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Peter's not said exactly how he plans to deal with
this, but I suppose it'll round off one way or the other ...
It'll get truncated by integer division. I wouldn't mind if someone
proposed a patch to create a warni
[EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on an undefined symbol?
T
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
How could there be a concurrent update of the _same_ row, when
I do "select * from bar *for update*".
AFAICT the spec doesn't require one to have written FOR UPDATE
in order to use WHERE CURRENT O
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Couldn't this be emulated by doing
begin;
declare foo cursor for select * from bar for update;
fetch foo into v_foo ;
update bar set abc='def' where ctid = v_foo.ctid;
That wouldn't follow
Gavin Sherry wrote:
On Mon, 24 Jul 2006, Golden Liu wrote:
begin;
declare foo cursor for select * from bar for update;
fetch foo;
update bar set abc='def' where current of foo;
fetch foo;
delete from bar where current of foo;
commit;
No one has stepped up to do this for 8.2 so unfortunately
Hi
I had a urge to do a bit of hacking today, and so I tried to implement
my idea about an pg_rotate_wal for postgres 8.1. It's basically a huge
hack, and wastes io bandwith - but it doesn't need any patches to 8.1,
and can be compiled as an extension.
Here is the code (Included, because it's
201 - 300 of 306 matches
Mail list logo
