Tom Dunstan wrote:
Here is an updated version of the enums patch. It has been brought up to
date and applies against current CVS HEAD. The original email is at [1],
and describes the implementation.
I'm sorry I missed the original discussions, but I have to ask: Why do
we want enums in core?
This patch implements
explain_analyze_timer = off
which prevents time instrumentation being taken during an
EXPLAIN ANALYZE. The output of EA is unaffected, so that all the times
come out as zero - this is done to ensure any programs that are parsing
this output can still recognise it.
On Tue, Dec 19, 2006 at 08:09:47AM +, Heikki Linnakangas wrote:
Tom Dunstan wrote:
Here is an updated version of the enums patch. It has been brought up to
date and applies against current CVS HEAD. The original email is at [1],
and describes the implementation.
I'm sorry I missed the
This is a patch for load distributed checkpoint discussed in
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00337.php
Only write() calls are smoothed, fsync() are not.
Existing checkpoint method is called immediate checkpoint in the patch,
and the new method called asynchronous
most of the parser work. What is left
hereafter is adjusting all the corner cases, the escaping rules, and
the various XML parser behaviors.
Use configure --with-libxml to build.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
xml-patch-20061219.bz2
Description: BZip2 compressed
Heikki Linnakangas [EMAIL PROTECTED] writes:
Ignoring my general dislike of enums, I have a few issues with the patch
as it is:
1. What's the point of having comparison operators for enums? For most
use cases, there's no natural ordering of enum values.
If you would like to be able to
Heikki Linnakangas wrote:
I'm sorry I missed the original discussions, but I have to ask: Why
do we want enums in core? The only potential advantage I can see over
using a look-up table and FK references is performance.
The difference is that foreign-key-referenced data is part of your data
Peter Eisentraut wrote:
Here is an updated updated XML patch. Unless there are objections of
the sort that this approach is totally wrong or there is crash
potential, I'd like to get this committed this week and fill in the
gaps next year.
Great. The XML section of the datatypes
ITAGAKI Takahiro wrote:
This is a patch for load distributed checkpoint discussed in
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00337.php
Only write() calls are smoothed, fsync() are not.
Existing checkpoint method is called immediate checkpoint in the patch,
and the new method
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
1. What's the point of having comparison operators for enums? For most
use cases, there's no natural ordering of enum values.
If you would like to be able to index enum columns, or even GROUP BY one,
you need those; whether
Andrew Dunstan wrote:
As for efficiency, I agree with what Tom says about alignment and
padding dissolving away any perceived advantage in most cases. If we
ever get around to optimising record layout we could revisit it.
I don't, because there are always those that are knowledgeable enough
Alvaro Herrera wrote:
Andrew Dunstan wrote:
As for efficiency, I agree with what Tom says about alignment and
padding dissolving away any perceived advantage in most cases. If we
ever get around to optimising record layout we could revisit it.
I don't, because there are always those
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as long as we're talking shoulds the
Heikki Linnakangas wrote:
I'm sorry I missed the original discussions, but I have to ask: Why do
we want enums in core? The only potential advantage I can see over using
a look-up table and FK references is performance.
Well, there are a few things. Sometimes its tidiness, sometimes
Alvaro Herrera wrote:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the patch at all so I'm not
Peter Eisentraut wrote:
An objection to enums on the ground that foreign keys can accomplish the
same thing could be extended to object to any data type with a finite
domain.
Exactly. The extreme case is the boolean type, which could easily be
represented by a two-value enum. Or, if you were
17 matches
Mail list logo
