On Saturday 2007-12-15 02:14, Simon Riggs wrote:
> On Fri, 2007-12-14 at 18:22 -0500, Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
> > > to drop (and log) rows that contain malformed data. That is, rows with
On Friday 2007-12-14 16:22, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
> > to drop (and log) rows that contain malformed data. That is, rows with
> > too many or too few columns, rows that result in constraint
On Wednesday 2007-03-14 08:26, Csaba Nagy wrote:
> On Wed, 2007-03-14 at 16:08, [EMAIL PROTECTED] wrote:
> > On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
> > > "David Fetter" <[EMAIL PROTECTED]> writes:
> > > > CREATE TABLE symptom (
> > > > symptom_id SERIAL PRIMARY KEY, /* S
On Tuesday 2006-06-06 20:11, Mark Woodward wrote:
> > Mark Woodward wrote:
> >> OK, here's my problem, I have a nature study where we have about 10
> >> video
> >> cameras taking 15 frames per second.
> >> For each frame we make a few transactions on a PostgreSQL database.
> >
> > Maybe if you grou
On Wednesday 2006-03-22 08:53, William ZHANG wrote:
> "Tom Lane" <[EMAIL PROTECTED]>
>
> > Timestamps and numerics are definitely in the spec, geometric and
> > network types are definitely not. IIRC, bitstring types are in SQL99
> > but for some reason are deprecated in SQL2003 (if anyone knows t
Without directly addressing the merits of enumerations, enumeration
interfaces, real currency and time zone types, or whether currency and time
zone types should be built using enumerations, I would like to ask the
powers-that-be to seriously consider radically modularizing Postgresql's type
sy
Sorry to interupt. The discussion is interesting, but I need some help to
follow along.
On Wednesday 2006-01-04 17:07, Josh Berkus wrote:
> Simon,
>
> > - Are there any performance issues that can be directly attributed to
> > mis-estimation of N-Distinct ("D") by the ANALYZE command?
>
> Yes.
On Thursday 2005-12-22 14:28, Lukas Kahwe Smith wrote:
> Bruce Momjian wrote:
> > Right, if the cardinality changes, you realize this before execution and
> > optimize/save the plan again. A further optimization would be to save
> > _multiple_ plans for a single prepared plan based on constants an
On Saturday 2005-12-17 16:28, Lukas Smith wrote:
> Bruce Momjian wrote:
> > * Flush cached query plans when the dependent objects change,
> > when the cardinality of parameters changes dramatically, or
> > when new ANALYZE statistics are available
>
> Wouldn't it also make sense to
On Thursday 2005-12-08 15:47, Simon Riggs wrote:
> does of course already exist, so the following should cause dependency
> violation ERRORs:
> - omitting the CASCADE when attempting to delete parent constraint
> - attempting to drop the child constraint
Why should dropping the child constraint f
It would be nice if Postgresql supported multi-octet raw data. Certainly a
lot of what you would do with it would be similar to bytea, but the basic
string functions would be overloaded so that the unit of work would be a
multi-octet word.
Multi-octet instances could be cast to bytea when on
Is it possible to submit a hand written or arbitrary execution plan to the
retrieval engine? (That is, can one bypass the SQL parser and planner or
optimizer and just provide instructions to nested loop join table a to table
b ...)
---(end of broadcast)-
On Thursday 2005-12-01 19:01, Gregory Maxwell wrote:
> On 12/1/05, Pollard, Mike <[EMAIL PROTECTED]> wrote:
> > Optimizer hints were added because some databases just don't have a very
> > smart optimizer. But you are much better served tracking down cases in
> > which the optimizer makes a bad ch
On Monday 2005-11-14 20:48, Tim Allen wrote:
OOPS deleted pg_xlog because surely it was only a log file.
>
> We've seen reports of people firing this particular foot-gun before,
> haven't we? Would it make sense to rename pg_xlog to something that
> doesn't sound like it's "just" full of log fil
On Thursday 2005-10-27 17:39, Michael Glaesemann wrote:
> On Oct 28, 2005, at 9:23 , Trent Shipley wrote:
> > On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
> >> Jim C. Nasby wrote:
> Relational databases already have a type for unordered sets: tables.
> IMO,
On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >Like I said, if we're going to support a concept of ordering of items in
> >an enum then we need to support it fully. For starters that means having
> >the ability to re-order things in an enum seamlessly.
>
> I do not see
On Tuesday 2005-10-04 13:54, Simon Riggs wrote:
> On Tue, 2005-10-04 at 18:16 +0200, Zeugswetter Andreas DAZ SD wrote:
> > > Another possibility is optimizing for the special case of
> > > indexing on a partitioning key. In this case, index values
> > > would be very localized to one table, so just
What is the relationship between database support for clustering and grid
computing and support for distributed databases?
Two-phase COMMIT is comming in 8.1. What effect will this have in promoting
FOSS grid support or distribution solutions for Postgresql?
---(end of
On Thursday 2005-09-22 13:16, Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >While I'm all for COPY from views, I think I'd rather have the syntactic
> >warts than code warts. ISTM that
> >
> >CREATE TEMP VIEW some_name AS SELECT * FROM table WHERE ...;
> >COPY some_name TO stdout;
> >
> >is much u
On Wednesday 2005-09-21 07:01, Hans-Jürgen Schönig wrote:
> Rod Taylor wrote:
> >>the problem is: COPY can write data returned by a SELECT statement to a
> >>file. our idea is to implement precisely that.
> >>
> >>example:
> >>
> >>COPY TO file_name USING some_select_statement;
> >
> > I have run i
20 matches
Mail list logo
