Am 23.01.14 02:14, schrieb Jim Nasby:
> On 1/19/14, 5:51 PM, Dave Chinner wrote:
>>> Postgres is far from being the only application that wants this; many
>>> >people resort to tmpfs because of this:
>>> >https://lwn.net/Articles/499410/
>> Yes, we covered the possibility of using tmpfs much earlie
Luke Lonergan wrote:
> I advocate the following:
>
> - Enable specification of TOAST policy on a per column basis
>
> As a first step, then:
>
> - Enable vertical partitioning of tables using per-column specification of
> storage policy.
>
Wouldn't it be enough to enable having the toast table o
Tom Lane wrote:
> "=?ISO-8859-1?Q?Ott=F3_Havasv=F6lgyi?=" <[EMAIL PROTECTED]> writes:
>
>> When using views built with left joins, and then querying against these
>> views, there are a lot of join in the plan that are not necessary, because I
>> don't select/use any column of each table in the v
Simon Riggs wrote:
> The objections to applying this patch originally were:
> 2. it would restrict number of digits to 508 and there are allegedly
> some people that want to store > 508 digits.
>
If 508 digits are not enough, are1000 digits be sufficient? Both limits
appear quite arbitrary to me
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
>
>> Simon Riggs wrote:
>>
>>> The objections to applying this patch originally were:
>>> 2. it would restrict number of digits to 508 and there are allegedly
>>> some people th
Andrew Dunstan wrote:
>
> I have no idea why that's done - it goes back to the origins of the
> syslogger - probably because someone mistakenly thinks all WIndows
> text files have to have CRLF line endings.
>
> I tried changing that to _O_BINARY, and calling _setmode on both the
> pipe before it's
Andrew Dunstan wrote:
>>
>>> I have no idea why that's done - it goes back to the origins of the
>>> syslogger - probably because someone mistakenly thinks all WIndows
>>> text files have to have CRLF line endings.
Yes this was intentional, notepad still doesn't like LF line endings.
Not my prefe
Andrew Dunstan wrote:
>
> Not for Wordpad though, and it's pretty universal too. And Notepad
> won't load a file of any great size anyway. Furthermore, we just can't
> have this alongside the pipe chunking protocol, so I'm inclined to
> blow it away altogether, unless there are pretty loud squawk
Alexey Klyukin wrote:
>
>
>> For what use cases do you think your WAL-based approach is better than
>> Slony/Skytools trigger-based one ?
>>
>
> A pure trigger based approach can only replicate data for the commands
> which fire triggers. AFAIK Slony is unable to replicate TRUNCATE
> comman
Michael Glaesemann wrote:
>
> On Oct 12, 2007, at 10:19 , Gregory Stark wrote:
>
>> It would make Postgres inconsistent and less integrated with the rest
>> of the
>> OS. How do you explain that Postgres doesn't follow the system's
>> configurations and the collations don't agree with the system
>>
Simon Riggs wrote:
My thinking was if you load a 1000 rows and they all have the same key
in your summary table then you'll be doing 1000 updates on a single row.
This is true because the statement level triggers are still rudimentary,
with no OLD and NEW support. A single AFTER statement tr
Robert Treat wrote:
On Friday 25 January 2008 06:40, Simon Riggs wrote:
Notes: As the syntax shows, these would be statement-level triggers
(only). Requesting row level triggers will cause an error. [As Chris
Browne explained, if people really want, they can use these facilities
to create a B
alexander lunyov wrote:
Guillaume Smet wrote:
I want to try new pg_dump to connect to old server, but i can't - old
postgres doesn't listening to network socket. Why postgres 6.5.3 not
binding to network socket? It started with this line:
Maybe you should just dump schema and data separately
alexander lunyov wrote:
Andreas Pflug wrote:
I want to try new pg_dump to connect to old server, but i can't - old
postgres doesn't listening to network socket. Why postgres 6.5.3 not
binding to network socket? It started with this line:
Maybe you should just dump schema and data
Andrew Dunstan wrote:
>
>
>> But Pg
>> should have some pretty print function - it is easy implemented there.
>> Personally, I prefere Celko's notation, it is little bit more compact
>>
>> SELECT sh.shoename, sh.sh_avail, sh.slcolor, sh.slminlen,
>> sh.slminlen * un.un_fact AS slminl
Tom Lane wrote:
In testing the TRIGGER WHEN patch, I notice that pg_dump is relying on
pg_get_triggerdef(triggeroid, true) (ie, "pretty" mode) to dump
triggers. This means that trigger WHEN conditions will be dumped
without adequate parenthesization to ensure they are interpreted the
same way wh
Tom Lane wrote:
stephen layland <[EMAIL PROTECTED]> writes:
I've written a quick patch against the head branch (8.4DEV, but it also
works with 8.1.3 sources) to fix LDAP authentication support to
work with LDAPS servers that do not need start TLS. I'd be interested
to hear your opinions on
Florian Pflug wrote:
But maybe you could store the whitespace appearing before (or after?)
a token in the parse tree that is stored for a view. That might not
allow reconstructing the *precise* statement, but at least the
reconstructed statement would preserve newlines and indention - which
Decibel! wrote:
There's no reason that the server has to deal with a text file. I
completely agree that there must be a method to change settings even if
the database isn't running, but that method does not necessarily need to
be a text file. If we can come up with a standard API for reading and
Aidan Van Dyk wrote:
* Andreas Pflug <[EMAIL PROTECTED]> [080604 10:20]:
Hiding the storage of config parameters opaquely behind an API is
something I've been hating for a long time on win32.
;-)
When reading this thread, I'm wondering if anybody ever saw a co
Tom Lane wrote:
>
> * Can we present the config options in a more helpful way (this is 99%
> a documentation problem, not a code problem)?
>
> * Can we build a "configuration wizard" to tell newbies what settings
> they need to tweak?
It's certainly one thing to create an initial postgresql.co
Greg Smith wrote:
On Thu, 5 Jun 2008, Magnus Hagander wrote:
We really need a "proper API" for it, and the stuff in pgAdmin isn't
even enough to base one on.
I would be curious to hear your opinion on whether the GUC overhaul
discussed in this thread is a useful precursor to building such a
David E. Wheeler wrote:
How about a simple rule, such as that machine-generated comments start
with "##", while user comments start with just "#"? I think that I've
seen such a rule used before. At any rate, I think that, unless you
have some sort of line marker for machine-generated comments
Gregory Stark wrote:
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
Why do so many people here insist on editing postgresql.conf as primary means
of changing config params?
Isn't a psql -c "SET foo=bar; MAKE PERSISTENT" just as good as sed'ing
postgresql.
Gregory Stark wrote:
So all you have is our existing file except with an additional layer of
quoting to deal with, a useless SET keyword to annoy users, and a file that
you need a bison parser
Don't you think that's a little over the top, throwing bison at the
simple task to extend postgresql.c
Gregory Stark wrote:
Text config files are NOT friendly for beginner and mediocre users. IMHO the
current restriction on GUC changes is a major obstacle towards pgsql tuning
tools, e.g. written as a Google SoC project. Graphic tools aren't too popular
at pgsql-hackers, but please contemplate a
Tom Lane wrote:
I grow weary of this thread. I will say it once more: I do not believe
for one instant that the current formatting of postgresql.conf is the
major impediment, or even a noticeable impediment, to producing a useful
configuration wizard. If you wish to prove otherwise, provide a
c
Gregory Stark wrote:
> "Andreas Pflug" <[EMAIL PROTECTED]> writes:
>
>> I personally wouldn't even think about starting such a wizard, unless I have
>> an
>> idea how to push the result into the database. No, not a file, but via SQL!
>> So
&
I've been following the thread with growing lack of understanding why
this is so hardly discussed, and I went back to the documentation of
what the restore_command should do (
http://www.postgresql.org/docs/8.3/static/warm-standby.html )
While the algorithm presented in the pseudocode isn't dealin
Heikki Linnakangas wrote:
> Andreas Pflug wrote:
>> I've been following the thread with growing lack of understanding why
>> this is so hardly discussed, and I went back to the documentation of
>> what the restore_command should do (
>> http://www.postgresql.org/d
Fujii Masao wrote:
> Hi,
>
> On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
> wrote:
>
>> Simon Riggs wrote:
>>
>>> If you do this, then you would have to change the procedure written into
>>> the 8.3 docs also. Docs aren't backpatchable.
>>>
>>> What you propose is *better* than raw
Heikki Linnakangas wrote:
No, no crash is involved. Just a normal server shutdown and start:
1. Server shutdown is initiated
2. A shutdown checkpoint is recorded at XLOG point 1234, redo ptr is
also 1234.
3. A XLOG_SWITCH record is written at 1235, right after the checkpoint
record.
4. The la
Tom Lane wrote:
> Not at all, because the database would be very unhappy at restart
> if it can't find the checkpoint record pg_control is pointing to.
>
So for several weeks now all postings just say how it will _not_ work.
Does this boil down to "There's no way to make sure that a graceful
fa
Andrew Dunstan wrote:
We're in Beta. You can't just go yanking stuff like that. Beta testers
will be justifiably very annoyed.
Please calm down.
pg_standby is useful and needs to be correct. And its existence as a
standard module is one of the things that has made me feel confident
about r
Simon Riggs wrote:
>>>
>>> No, because as I said, if archive_command has been returning non-zero
>>> then the archive will be incomplete.
>>>
>> Yes. You think that's wrong? How would you like it to behave, then? I
>> don't think you want the shutdown to wait indefinitely until all files
>
PostgreSQL 7.3.2
CREATE DOMAIN testdom AS int4;
CREATE TABLE testtab(testcol testdom);
INSERT INTO testtab VALUES (1);
INSERT INTO testtab VALUES (2);
VACUUM ANALYZE testtab;
SELECT * FROM testtab WHERE testcol > 1;
The select will give
"ERROR: convert_numeric_to_scalar: unsupported type 33814
Trying to connect from pgadmin2, I get the message
"no pg_hba.conf entry for ..."
I found that the ip address matching with rangeSockAdr in line 651 in
hba.c fails.
I get access if I set ipaddr/mask to 0.0.0.0/0.0.0.0 in pg_hba.conf.
---(end of broadcast)-
Ok Bruce,
I found out what's happening.
I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by
default. When connecting locally over IP (pgaccess), hba is checked
against IPV6 patterns in pg_hba.conf.
My pgadmin2 machine will connect with an IP4-to-6 mapped address of
0::c0
Tom Lane wrote:
I've applied a patch to fix this, but can't try it out here for lack of
any IPv6 infrastructure ... please check it.
regards, tom lane
I tried it, and it works.
Regards,
Andreas
---(end of broadcast)---
TIP 2: you can get of
Christopher Kings-Lynne wrote:
1. Do we want to someday allow groups to have groups as members? (Seems
reasonable to me.)
I agree.
I think the other requirement of roles is that they are able to own objects.
ie. we need to allow groups to own objects.
This would also solve the prob
Christopher Kings-Lynne wrote:
We make pg_get_xxx2 functions that return a formatted version. Internally,
we just add an extra boolean parameter to the pg_get_triggerdef() function
in ruleutils and we call that true or false depending...
That's what I got too!
Several weeks ago I proposed such
Tom Lane wrote:
I recall objecting to someone who wanted to remove "unnecessary"
parentheses, but I can't see any risk in inserting unnecessary
whitespace.
That "someone" was me indeed, and as I mentioned the code is completely
separated from the code that pg_dump uses. Thus, there's *no way* tha
Rod Taylor wrote:
What I *really* want is having the original source stored, including
comments, version info, ... Currently, it's argued that underlying table
and column might change, braking the view/rule. This could be
restricted, or source could be dropped (alter table ... cascaded). Is it
David Blasby wrote:
Sebastien Lemieux wrote:
Hi,
I need to extend postgreSQL to support some specific function I
will code in C (ideally C++ if it can work!).
Be very carefull with using C++ functions inside postgresql. If the
C++ code throws an exception the postgresql backend will get
Christopher Kings-Lynne wrote:
this arguments are quite academic.
You what!
On one side, this could be
restricted, thats what pg_depends is good for (this already happens for
inherited tables).
On the other side, how often do you rename columns or tables?
You what!
On mssql, n
Hi Christopher,
Sorry if I offended you.
I wasn't offended because I wasn't sure what you wanted to say to me.
You may call me the biggest fool of all, as long you do it in Sualheli,
or Korean... :-)
'You what!' is what you say when you cannot
believe what someone is saying... Calling 'stabl
Alvaro Herrera wrote:
On Wed, Jun 18, 2003 at 12:59:36PM +0200, Andreas Pflug wrote:
What I need again and again, is changing the size of a column (rarely
the type). For pgsql, I'd have to drop the column, and need to recreate
all views. For MSSQL, it won't matter if the column
I wonder if there's a way to read all allowed user/database variables
that can be set/reset.
I'd like to have this self-configured in pgAdmin3 instead of hard-coded.
Can you give a hint?
Regards,
Andreas
---(end of broadcast)---
TIP 2: you can get
Tom Lane wrote:
Look at SHOW ALL, maybe?
Of course Sorry.
If you're willing to think about a solution that would only exist
starting in 7.4 --- some of my cohorts at Red Hat are about to submit
patches that create a separate "pg_guc" executable that contains
another copy of the backend's GUC
Tom Lane wrote:
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
SHOW ALL;
Will help, but won't tell the whole story...
See my followup. Which bits of info would you like to see added that
SHOW doesn't reveal?
I'd like to have type (bool/numeric/alpha/value list), min, max and
Tom Lane wrote:
Yes, you can check if they're binary compatible from the pg_cast table
But nearly all of the interesting cases require you to understand the
type's interpretation of typmod, and you can't learn that from a table.
How many cases are there where blindly looking for a binary-
Andreas Pflug wrote:
I'd like to have type (bool/numeric/alpha/value list), min, max and
values in pg_settings.
Currently, you can select the name from a combobox, but type any value
you like, waiting for the backend to complain (or accept).
Additionally, it should be marked which var
Tom Lane wrote:
I spent weeks doing hash aggregates, weeks doing IN-subselect
optimization, and am in the middle of many weeks on FE/BE protocol
improvement. I am sorry that you don't see these as killer features
... but they are all things that we desperately needed to do.
For me, the 7.4 enh
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into
Rod Taylor wrote:
Oh, one more thing --- right justify isn't as accepted as left-justify
But it looks so much better...
Ye!
Consider this:
SELECT foo
FROM bar b
LEFT JOIN chair c USING (thekeycol)
WHERE ...
:-)
versus
SELECT foo
FROM bar b
LEFT JOIN chair c USING (thekeycol)
WHE
Bruce Momjian wrote:
I don't think an option to do such justification would be good unless we
can do it consistenly in the code, and there is enough demand.
It's no big additional effort to do this, and going back and forth is
not a big problem. I wouldn't invent an option for that, just do it.
Christopher Kings-Lynne wrote:
I was considering adding this and the stuff Andreas requested to
pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's
important to kept them consistent with pg_settings). Were the Red Hat
guys going to do this?
pg_settings would be fine for php
Jan Wieck wrote:
Change that into "* Remove bugs from source code" and get a patent on
it. Should be a nobrainer (as in those guy's have no brains)
considering that NetFlix even got a patent on DVD subscription rentals:
http://slashdot.org/article.pl?sid=03/06/24/1458223&mode=flat&tid=155&tid=9
johnn wrote:
On Wed, Jun 25, 2003 at 10:30:31AM -0500, Andrew Dunstan wrote:
DB2 looks good. I have horrid, horrid memories of wrestling with the
Oracle "extent" madness.
I do think that it's worth providing additional access points to
tablespaces, though. That is, it would make sense
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into co
Francisco Figueiredo Jr. wrote:
Hi all,
I'm getting the following error when trying to do an initdb:
This user must also own the server process.
initializing pg_depend... ERROR: expression_tree_walker: Unexpected
node type 601
IN: expression_tree_walker (clauses.c:2320)
Hi Francisco,
I had
I noticed the new expression functionality of indices and while
implementing them in pgadmin3 was wonderingnow to extract the definition
from the catalog.
Consider an index that looks like this:
CREATE INDEX foo ON bar (numcol, length(txtcol), intcol2,
length(txtcol2))
Looking at pg_index:
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I noticed the new expression functionality of indices and while
implementing them in pgadmin3 was wonderingnow to extract the definition
from the catalog.
The best way is to use pg_get_indexdef(indexOID), same as pg_dump an
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
pg_get_indexdef converts that string to a list of nodes (not
surprising), while pg_get_expr whill join these list elements with an
explicit and (according to a comment, needed for partial index). Do I
need to retrieve indexp
Bruce Momjian wrote:
I usually do it, but it might take a week to put together.
---
Robert Treat wrote:
Once you folks are done going through the remaining list of patches, can
we get someone to send a rough list of new f
The current snapshot won't initdb, because running
information_schema.sql fails.
The two occurences of "WHERE u.usesysid = ANY( g.grolist )" are the
problem. Replacing the ANY clause with some dummy will let everything
run ok.
select usename from pg_user, pg_group where usesysid = ANY (grolist)
Joe Conway wrote:
Andreas Pflug wrote:
The current snapshot won't initdb, because running
information_schema.sql fails.
The two occurences of "WHERE u.usesysid = ANY( g.grolist )" are the
problem. Replacing the ANY clause with some dummy will let everything
run ok.
sele
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I just checked out (at the moment hba.c changed, so I had to redo it),
make clean, make, pgsql stop, make install, pgsql start and it's still
there.
It works fine for me too. Try removing
src/backend/parser/gra
We wouldn't like to have it called Ingres too...
Spoken language is different from written, so docs should be precise.
PostgreSQL is a mark, and should be used as careful as it deserves.
Regards,
Andreas
Christopher Kings-Lynne wrote:
I just seem to recall a discussion where we decided to 'stand
Bruce Momjian wrote:
Here are the changes for 7.4. I am looking for any improvements. This
will be adjusted as we move through beta.
---
Add FOR EACH STATEMENT statement-level triggers (Neil Conway)
AFAICS the current implem
Joe Conway wrote:
Andreas Pflug wrote:
But PostgreSQL may be better than Oracle, don't you think? In the
named document,
MSSQL2000 still doesn't have row level triggers, and I doubt that
2003 has.
Right, so as you've pointed out, Postgres trigger implementation is at
lea
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
- Implement a way to enable triggers to check which columns are affected
by the triggering statement.
This can already be done by comparing old and new values, no?
No, this is not the case.
UPDATE foo SET x=x, y=y
is dif
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Consider this:
Table with one column that is maintained by a trigger for this rule:
- Only one row in a group of rows may have a foo-value of "true", all
others must be "false".
- If foo=true is inserted/upda
Bruce Momjian wrote:
Andreas Pflug wrote:
YATS (yet another TODO suggestion):
provide an official and reliable way to temporarily enable/disable triggers.
"ALTER TABLE xxx ENABLE/DISABLE TRIGGER ALL/trgName"
We still have that nasty "not presently checked everywhere it should
vailable...
Regards,
Andreas
Bruce Momjian wrote:
Do you have suggested wording?
-------
Andreas Pflug wrote:
Bruce Momjian wrote:
Here are the changes for 7.4. I am looking for any improvements. This
will
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This can already be done by comparing old and new values, no?
No, this is not the case.
UPDATE foo SET x=x, y=y
is different from
UPDATE foo SET y=y
if triggers maintaining x are involved.
Bruce Momjian wrote:
It might be a bit risky getting pg_dump to use it though?
I don't think we every want pg_dump to use it --- better accurate than
pretty in there.
Agreed.
There seems to be some tough assumptions that have to
be made in that function that are better used for visual-only c
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
So if you agree that there is a quoting problem,and you don't mind
breaking backwards compatibility for it, I'll do a complete patch...
I don't see any backwards-compatibility issue, because usernames
containing double quo
I'm not sure this is a fair assessment of statement level triggers.
Yes, in MSSQL you can access the rows involved in the statement, but
in Oracle you cannot (emphasis added):
"Accessing Column Values in Row Triggers
Within a trigger body of a *row trigger*, the PL/SQL code and SQL
statements
Bruce Momjian wrote:
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
It might be a bit risky getting pg_dump to use it though?
I definitely don't want pg_dump using the pretty-print stuff ;-).
I'm neutral on whether to use it in psql's \d commands.
I thought
Neil Conway wrote:
On Mon, Aug 04, 2003 at 10:47:36AM +0200, Andreas Pflug wrote:
AFAICS the current implementation still doesn't have a way to access the
affected rowset, so it'a pretty much like a SELECT without a WHERE.
Yeah, unfortunately I didn't get a chance to
Bruce Momjian wrote:
How are statement level triggers supposed to work? Are they just
triggers deferred until the end of the statement? You mentioned access
to the affected rows, but I don't understand how that is supposed to
happen.
Statement level isn't about deferring or grouping the trigg
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I wonder why you are suggesting workarounds for features that other
databases provide.
The fact that other databases provide 'em doesn't make them good ideas.
In particular, writing a trigger that assumes that
Tom Lane wrote:
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP
DOMAIN be able to drop a type?
Don't care much about either of those; the current state of
affairs is fine with me.
What happens in the future
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
It just seemed complex to figure out which operators needed parens and
which didn't.
The fact that the first attempt was wrong doesn't improve my faith in
that code one bit ;-).
It was posted expressiv
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Only very-well-documented operators (Chapter 4.1.6) are parens-optimized
(+-*/%);
At the moment ... but you can be sure there will be demand to get smarter.
I never claimed to implement the ultimate solution, just
I propose that the following should be added to the TODO list:
- expose read-only NEW/OLD rowsets in statement-level triggers that
represent the affected rows.
- Implement a way to enable triggers to check which columns are affected
by the triggering statement.
Regards,
Andreas
-
Andrew Dunstan wrote:
I did have a thought that it could be done lazily (on backend startup)
on other databases and immediately on the current database. I guess it
depends on the cost of checking for such things - wouldn't want to add
greatly to startup time.
That would leave a small window of
Andrew Dunstan wrote:
Regarding second item, I don't think anyone suggested autodropping
objects, or else I misunderstood. (That would be dangerous, to say the
least, IMHO).
I agree, but some applications might use tables dedicated to a specific
user. While this is IMHO not a good style to us
Christopher Browne wrote:
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Bruno Wolff III) transmitted:
On Fri, Aug 08, 2003 at 15:32:05 +0530,
Rahul_Iyer <[EMAIL PROTECTED]> wrote:
hi, im currently working on a project that requires batch
operations - eg. Batch i
Bruce Momjian wrote:
Still, if there's something not precise, it should be cleared. Which
tough assumptions are made that seem doubtful to you?
It just seemed complex to figure out which operators needed parens and
which didn't.
Only very-well-documented operators (Chapter 4.1.6) a
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:
I throw last nights backup at it. Data went in in about 1/2 an hour then
the
constraints went in and they took at age. about 2 hours.
Is there anyway to speed up the database constraint code? Because qui
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
That really needs to be rewritten to do a single check over the table
rather than running the constraint for every row. I keep meaning to get
around to it and never actually do. :( I'm not sure th
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
That really needs to be rewritten to do a single check over the table
rather than running the constraint for every row
Stephan Szabo wrote:
I don't know if there will be or not, but in one case it's a single table
select with constant values, in the other it's probably some kind of scan
and subselect. I'm just not going to rule out the possibility, so we
should profile it in large transactions with say 100k single
Dann Corbit wrote:
Simplification of bulk operations can be very important for customers
(on the other hand). For the CONNX tool set, we offer an escape on
INSERT/SELECT that performs the operation in bulk mode.
There are serious downsides to bulk operations also (such as not being
logged and the
Dann Corbit wrote:
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 11:36 AM
To: Dann Corbit
Cc: Stephan Szabo; PostgreSQL-development
Subject: Re: [HACKERS] [GENERAL] 7.4Beta
Dann Corbit wrote:
Simplification of bulk operations can be
Bruce Momjian wrote:
2. SSL. Postmaster allows SSL for AF_INET but not AF_INET6.
This is fixed and works now.
Regards,
Andreas
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail co
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not transaction based and cannot be rolled back.
Just wondering, what other databases has transactable DDLs? oracle seems to
have autonomous
Shridhar Daithankar wrote:
On 21 Aug 2003 at 9:21, Greg Stark wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
a
1 - 100 of 518 matches
Mail list logo
