t causes the AM/PM indicator simply to never work except at the end of
the string, I see no possible justification for not backpatching the fix.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)-
imate is larger than this, a hashed subplan will not be used since
it does not spill to disk; instead it will use a plain subplan.
Rewrite the query as an outer join and you will be much better off.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> Um, what? Under what conditions is it permissable for simple arithmetic on
>> (only) timestamptz values (which may have originated in different timezones
>> ne
ifference is that a user in US/Eastern might, under
some circumstances, wish to regard that time period as '1 day' rather
than 25 hours; no user in any other timezone would do so. Since the
conversion from '25 hours' to '1 day' loses information, it should not
m, what? Under what conditions is it permissable for simple arithmetic on
(only) timestamptz values (which may have originated in different timezones
neither of which is the current one) to be dependent on the current timezone
setting?
--
Andrew, Supernews
http://www.supernews.com - indiv
t;>> test(> '2005-10-29 13:22:00-04'::timestamptz);
>>> ?column?
>>> --
>>> 25:00:00
>>> (1 row)
>
>> Is that actually the correct answer?
>
> I'm of the opinion that the correct answer, or at least the usually
the (not
inconsiderable) amount of work needed to implement it, since the performance
overhead of copying the data via the socket instead is not a large factor
in the overall cost of a large copy.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
-
her the WHERE clause of a rule will
be matched, so the rule is always expanded the same way, and the WHERE
clause becomes part of the rewritten command.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)-
On 2005-07-06, Oliver Jowett <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews wrote:
>> The problem is that even with the unnamed statement and deferred planning,
>> the planner still has to treat the parameters as variables, not constants,
>> since nothing in the prot
ly
where function calls are involved and major optimizations can be made on
constant values as a result of inlining.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 3: if posting/r
estamp value in the
database is stored, it's hard to see how it could be made switchable at
runtime.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 3: if posting/reading t
On 2005-05-21, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> On 2005-05-21, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> initdb does not use libpq ... it might link to it,
>
>> Linking to it is enough to bring in l
On 2005-05-21, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> The reason for the hang is that the sending end of the pipe from initdb
>> to postgres is not being closed by popen(), so postgres never sees EOF
>> on it. In th
that in due
course)
The reason for the hang is that the sending end of the pipe from initdb
to postgres is not being closed by popen(), so postgres never sees EOF
on it. In this context I am suspicious of the fact that while libpq is
being built with threading, the apps which link against it do
the
Unix standards clearly specify that sockaddr_storage must be both sized
and aligned such that a sockaddr_* struct for any supported protocol
can be stored there.
See the entry for in the Headers chapter of the
Base Definitions volume of the SUSv3.
--
Andrew, Supernews
htt
On 2005-04-29, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> I did some analysis for this one when it was mentioned just now in the irc
>> chan. I can reproduce on 7.4.x as follows:
>
>> test=> set timezone to
(not timestamptz) which
causes the other version of age() to be used instead. So this is obviously
a timezone-related issue. Couldn't reproduce on 8.0.1 with any timezone.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
if (pc->flags & TOASTED)
(that test could be moved into the setup phase, of course)
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
# create function crashme() returns text as 'select timeofday()'
test-# language sql stable;
CREATE FUNCTION
test=# begin;
BEGIN
test=# declare t cursor with hold for select crashme() as x from pg_class;
DECLARE CURSOR
test=# commit;
server closed the connection unexpectedly
--
Andrew,
or the merge join, but it appears to
be reducing its total cost estimate below that of the child nodes on the
assumption that the join can be aborted early, which is clearly not the
case for outer joins.
--
Andrew, Supernews
http://www.supernews.com - individual and corpor
(easily fitting in
one page) that index scans are as fast as or faster than seqscans for
doing simple one-row lookups provided the tables are in cache.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)-
On 2005-03-23, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> Changing the order so that the referenced table is fully populated, or at
>> least populated with more than a handful of pages of rows, before doing
>> _any_ ins
because when the first insert happens
on a referencing table, there will be no reason for the planner to prefer
a sequential scan. So this result is not surprising at all.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
--
pin that
down to the same problem (especially since such a restore should be filling
the referenced table before the referencing table).
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)
f
constraints until after the data load (which can be quite inconvenient in
some cases).
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On 2005-01-25, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> The problem is that the semantics of the &< and &> operators for the box
>> type are not what rtree needs for the "OverLeft" and "OverRigh
fixing this:
1) change the semantics of &< and &> to match rtree's expectations
2) replace &< and &> in the opclass with operators that behave as rtree
expects (this will have the side effect of rendering &< and &> un-indexable)
3) change rtree's
hich was the
only other place I found where constraint_name is used without any table
name being present. I don't know what the spec says, but it seems that
something is assuming that constraint_name is unique within the schema,
which of course is not the case in the above example.
--
Andrew, S
talk about providing macros
> for more flexible specification of rpath, so we can fix the problem if
> we can get the Perl library path, but I'm unsure where to learn that.
Oddly enough, that's what ccdlflags is for. So you'd end up removing that
info from ldopts only to add
On 2004-11-16, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> As I originally said in IRC, I do not know why the configure script is
>> trying to second-guess the ExtUtils::Embed output; however, what it is
>> doing c
d just set
perl_embed_ldflags to the output of `perl -MExtUtils::Embed -e ldopts`.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
31 matches
Mail list logo
