spi_printtup() has the following code (spi.c:1798):
if (tuptable->free == 0)
{
tuptable->free = 256;
tuptable->alloced += tuptable->free;
tuptable->vals = (HeapTuple *) repalloc(tuptable->vals,
tuptable->alloced * sizeof(HeapTuple
On Mon, Aug 17, 2015 at 7:56 AM, Tom Lane wrote:
> Hi Neil! Long time no see.
Likewise :)
>> Attached is a one-liner to double the size of the table when space is
>> exhausted.
>
> I think this could use a comment, but otherwise seems OK.
Attached is a revised patch with a comment.
> Should w
2012/3/19 Qi Huang :
>> I actually tried to find out, personally...not sure if I was searching
>> wrongly, but searching for TABLESAMPLE did not yield a cornucopia of
>> useful conversations at the right time in history (~2007), even when
>> the search is given a broad date-horizon (all), so I, too
I tried $subject recently, and noticed some minor issues:
(1) Two warnings that suggest bugs; in src/backend/utils/adt,
datetime.c:3101:27: warning: use of logical || with constant operand;
switch to bitwise | or remove constant
And similarly for src/interfaces/ecpg/pgtypeslib/interval.c. Attach
On Sun, Aug 1, 2010 at 7:40 PM, Tom Lane wrote:
> I tried to duplicate your results using what I believe to be the latest
> version of clang,
I'm using SVN tip of llvm+clang from ~one week ago.
>> (2) clang doesn't support (or require) "-no-cpp-precomp", which
>> src/template/darwin adds to $CC
On Sun, Aug 1, 2010 at 9:40 PM, Tom Lane wrote:
> I'm still wondering about the bleats I saw for -fwrapv though.
> configure already is set up to install that switch only conditionally:
>
> # Disable optimizations that assume no overflow; needed for gcc 4.3+
> PGAC_PROG_CC_CFLAGS_OPT([-fwrapv])
Andrew Dunstan wrote:
I'm not convinced it would be a huge gain anyway. Switching madly in
and out of the perl interpreter at least is a known performance
problem, IIRC
Returning control to the backend for every row returned would likely be
excessive, but you could return once every k rows an
D'Arcy J.M. Cain wrote:
On Tue, 20 Mar 2007 11:24:00 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
# -Make 64-bit version of the MONEY data type
Actually, this TODO is DONE. It's in HEAD now.
That is what the "-" prefix denotes.
-Neil
---(end of br
Bruce Momjian wrote:
Someone has pointed out that the following files have the 4-part BSD
copyright, which includes the advertising clause:
src/backend/port/darwin/system.c
src/backend/port/dynloader/freebsd.c
src/backend/port/dynloader/openbsd.c
src/backend/port/
Bruce Momjian wrote:
FYI, I have received permission, below, to remove the Andrew Yu
copyright. Thanks.
Can't we just remove the file outright? The last release of Ultrix was
in 1995.
-Neil
---(end of broadcast)---
TIP 3: Have you checked
In CVS HEAD:
contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
in this function
Induced by the recent pg_verifymbstr() patch.
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http:/
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
> The problem is that most of the standard methods are platform dependent, as
> they require MAC addresses or a "good" random source, for instance.
http://archives.postgresql.org/pgsql-patches/2007-01/msg00392.php
ISTM random() or simila
On Thu, 2007-04-12 at 11:45 -0400, Alvaro Herrera wrote:
> This phrase is missing a verb:
> [...]
> I find this markup strange:
> [...]
> In ResetTempTableNamespace(void), shouldn't it be using myTempNamespace
> instead of the SysCache lookup?
All fair points: I've applied the attached patch. Than
On Mon, 2007-04-16 at 03:48 +0200, Florian G. Pflug wrote:
> I just realized that this file isn't even in the postgresql CVS
> repo. But it _is_ part of the SVN mirror at
> https://projects.commandprompt.com/public/pgsql/repo.
[...]
> Seems to be a bug in the CVS->SVN conversion process...
The roo
The error message we currently produce when a deadlock occurs is pretty
unfriendly:
ERROR: deadlock detected
DETAIL: Process 32068 waits for AccessExclusiveLock on relation
16413 of database 16384; blocked by process 32064.
Process 32064 waits for AccessExclusiveLock on relation
On Fri, 2007-04-20 at 02:55 -0400, Tom Lane wrote:
> I don't think you've thought of quite all of the failure cases. One
> that's a bit pressing is that a deadlock isn't necessarily confined to
> objects in your own database.
I'm not sure I follow. If we conditionally acquire the locks we need an
On Sat, 2007-04-21 at 02:38 -0400, Tom Lane wrote:
> Maybe so, but you're going to be writing quite a lot of duplicative
> code, because the existing routines you might have been thinking of
> using (lsyscache.c etc) don't behave that way.
Right, I'm envisioning doing a conditional LockAcquire and
On Sat, 2007-04-21 at 17:56 -0400, Neil Conway wrote:
> Right, I'm envisioning doing a conditional LockAcquire and then
> heap_open() / heap_getnext() by hand. That will be relatively slow, but
> code that emits a deadlock error message is almost by definition not
> per
On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
> Attached patch does following conversions:
ISTM it would be cleaner to use an enum to identify the different
variants of the DISCARD command, rather than a character string.
Is guc.c still the logical place for the implementation of DISCARD?
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
> Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are satisfied
with this solution, I can get a cleaned up patch ready to apply shortly.
-Neil
---(
In a PL/PgSQL set-returning function, returning the result set of a
query requires a FOR loop and repeated invocations of the RETURN NEXT
statement:
FOR x in SELECT ... LOOP
RETURN NEXT x;
END LOOP;
This works, but it seems overly verbose. It occurred to me that we could
easily ad
On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
> I'm really still opposed to the entire concept. You're proposing to put
> a lot of fragile-looking code into a seldom-exercised error path.
There's certainly not a "lot" of code: the patch just adds a few
syscache lookups, wrapped in a PG_LOCK_
On Mon, 2007-04-23 at 17:48 -0400, Tom Lane wrote:
> I think we've got something isomorphic to that in the patch queue
> already --- take a look at Pavel's "table function" patch. It's in
> need of cleanup but I think it will make it in.
Interesting -- I missed that patch, but it seems like a bet
On Tue, 2007-04-24 at 07:58 +0200, Pavel Stehule wrote:
> It is RETURN TABLE(SQL) via ANSI SQL 2003
I think there are two basically orthogonal features in the patch: the
"RETURNS TABLE" addition to CREATE FUNCTION, and the "RETURN TABLE"
statement in PL/PgSQL. The former is specified by the SQL st
[ CC'ing -hackers ]
On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote:
> This patch adds a sentence on monitoring.sgml explaining that
> stats_row_level needs to be enabled if user wants to get last
> vacuum/analyze execution time.
This behavior was introduced in r1.120 of postmaster/p
On Thu, 2007-04-12 at 14:56 -0700, Andrew Hammond wrote:
> I've written the following function definitions to extend
> generate_series to support some temporal types (timestamptz, date and
> time). Please include them if there's sufficient perceived need or
> value.
I could see these being useful,
On Tue, 2007-04-24 at 18:04 +0300, Marko Kreen wrote:
> Attached patch addresses all 3 comments. As it will be
> top-level command, I put code into commands/discard.c
Applied with some minor tweaks -- thanks for the patch. I didn't bother
moving the regression tests out of guc.sql, although they
On Tue, 2007-04-24 at 17:38 -0400, Neil Conway wrote:
> which included other modifications to reduce the pgstat I/O volume in
> 8.1. I don't think this particular change was wise
I looked into this a bit further:
(1) I believe the reasoning for Tom's earlier change was not t
I haven't read the rest of the thread yet, but is this hunk not buggy?
yylex() is side-effecting, so the two calls to yylex() do not do what
the comment suggests.
> *** 2083,2091
> check_FROM = false;
> }
>
> ! /* check FROM keyword after direction's specification */
On Fri, 2007-04-27 at 07:36 +0200, Pavel Stehule wrote:
> it's true. There is bug. I'll send actualised version tomorrow.
No need: I fixed the bug and applied the patch. Thanks for the patch.
-Neil
---(end of broadcast)---
TIP 6: explain analyze
On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote:
> (1) I believe the reasoning for Tom's earlier change was not to reduce
> the I/O between the backend and the pgstat process [...]
Tom, any comments on this? Your change introduced an undocumented
regression into 8.2. I think yo
Pavel, my apologies for not getting back to you sooner.
On Wed, 2007-25-04 at 07:12 +0200, Pavel Stehule wrote:
> example: I have table with attr. cust_id, and I want to use parametrized
> view (table function) where I want to have attr cust_id on output.
Hmm, I see your point. I'm personally sa
What is the reasoning behind having two different implementations of the
datetime types, with slightly different behavior? Do we intend to keep
supporting both FP- and integer-based datetimes indefinitely?
Clearly, there are some costs associated with maintaining two different
implementations:
(1
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
> We've so far managed to avoid having any hard dependency on a working
> int64 type, but this would certainly be one. I don't really think the
> code-size-reduction argument is strong enough to justify that.
What benefit do we get from avoiding
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
> What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
-Neil
---(end of broadcast)---
TIP 7: You can help support the P
On Sun, 2007-06-05 at 13:09 -0400, Bruce Momjian wrote:
> Also, are we sure we can load a dump that used the float format? What
> happens for a date out of int8 range?
AFAIK we should always be able to reload timestamp values that are in
the legal range for an int8-based timestamp. For values out
On Wed, 2007-09-05 at 01:07 +0530, Raja Agrawal wrote:
> We are using the following piece of code for updating a list
> synchronously i.e. no two threads would update the list at a time.
Do you mean threads or processes?
> Is the following way of using semaphores not correct in the postgres
> env
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararraysel(), which in turn estimates the selectivity of
*each* array e
On Sat, 2007-12-05 at 14:26 -0700, Joshua D. Drake wrote:
> Either way, we are taking the hit, it is just a matter of where. IMO it
> would be better to have the information in the database where it makes
> sense, than pushing out to a log
If performance monitoring information is provided as a d
On Wed, 2007-16-05 at 11:25 -0400, Bruce Momjian wrote:
> Are we agreed to wait for 8.4 for this?
Yes.
-Neil
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/abo
On Fri, 2007-18-05 at 11:47 -0500, Jim C. Nasby wrote:
> Assuming the concurrent psql stuff gets in, do you still see a use for
> this?
I think concurrent psql (and/or async libpq) is the right way to handle
this sort of requirement. "DROP INDEX NOWAIT" is hacky, and would be
difficult (impossible
On Fri, 2007-18-05 at 13:29 -0400, Alvaro Herrera wrote:
> I think what Joshua really wants is an equivalent of this
That's not what his original email asked for, at any rate.
> start:
> BEGIN;
> LOCK TABLE foo IN ACCESS EXCLUSIVE MODE NOWAIT;
> -- if fail, rollback and go to st
On Fri, 2007-18-05 at 21:59 -0400, Tom Lane wrote:
> I kinda think this is emphasizing the wrong end of the process.
I don't disagree, but I think a tool like this would still be enormously
helpful (to me, at any rate). While there's more to the process of
feature development than just mailing pat
If both libedit and libreadline are available, we currently default to
linking against libreadline, unless the "--with-libedit-preferred"
configure option is used. Why do we default to preferring GNU readline
over libedit?
libedit is clearly preferable for license reasons. You could make the
argum
On Tue, 2007-29-05 at 16:01 -0400, Tom Lane wrote:
> (I imagine someday we'll get around to allowing int8 to be pass-by-value
> on 64-bit platforms.)
This could really be a significant performance win: I'm planning to take
a look at doing it for 8.4.
-Neil
---(end of br
On Mon, 2007-28-05 at 15:24 -0400, Tom Lane wrote:
> readline has much more functionality
Fair enough, that's probably a good enough reason to leave things as
they are for now.
-Neil
---(end of broadcast)---
TIP 5: don't forget to increase your f
On Fri, 2007-07-13 at 14:11 +0300, Martin Pihlak wrote:
> I'm working on a patch to extend the stats collector to handle stored
> procedure
> statistics (call counts, duration etc). The goal is to make this information
> visible via pg_stat functions/views. The collection would be controllable via
On Fri, 2007-07-13 at 15:38 -0500, Jim C. Nasby wrote:
> According to http://developer.postgresql.org/index.php/Feature_Matrix,
> 8.2 has non-blocking CREATE INDEX, which is news to me. Is it correct?
http://www.postgresql.org/docs/8.2/static/sql-createindex.html
See the CONCURRENTLY clause.
-Ne
To review, Pavel Stehule submitted a proposal and patch to add support
for "table functions" a few months back:
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php
http://archives.postgresql.org/pgsql-patches/2007-05/msg00054.php
Pavel proposed two basically independent features:
(
On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
> So what are *you* doing about it? This is open source, where if you want
> it and it's not there you make it. Otherwise you're just one more
> whinger wanting something for nothing.
I don't agree with this attitude at all: we should be l
On Mon, 2007-08-27 at 11:00 -0400, Andrew Dunstan wrote:
> In the longer run I want to make the whole system more data driven, so
> that it's comparatively easy for someone to add stuff.
I don't mean to hijack your thread, but I wonder if maintaining two
separate build systems is the best approac
On Wed, 2007-08-29 at 13:53 -0400, Tom Lane wrote:
> Why wouldn't we just remove the README files altogether? I can't
> see maintaining duplicate sets of documentation.
I agree that duplication is bad, but I think README files in the
individual contrib directories is useful and worth keeping: if
On Wed, 2007-08-29 at 22:41 +0200, Florian G. Pflug wrote:
> Or are platforms with INT64_IS_BUSTED no longer supported,
> and are all those #ifdefs only legacy code?
Personally I think we should head in that direction: if we enable
integer datetimes by default in 8.4 (per earlier discussion), such
On Sun, 2007-02-09 at 13:04 -0500, Kenneth Marshall wrote:
> 2. Evaluate the performance of different hash index implementations
>and/or changes to the current implementation. My current plan is
>to keep the implementation as simple as possible and still provide
>the desired performance
On Mon, 2007-09-10 at 21:04 -0400, Tom Lane wrote:
> I have just noticed that a column "txn_start" has appeared in
> pg_stat_activity since 8.2. It's a good idea, but who chose the name?
Me.
> I'm inclined to rename it to "xact_start", which is an abbreviation
> that we *do* use in the code, and
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
> The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps "off", "pl", and "all"
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
func
On Tue, 2007-25-09 at 22:15 -0400, Tom Lane wrote:
> I believe that (1) is now committed (renamed to RETURN QUERY),
> but what is the status of (2)?
>
> Personally I won't cry if this doesn't make it into 8.3, particularly
> since there was some disagreement about it. But if you intend to make
>
On Thu, 2007-10-04 at 09:04 +0200, Guillaume Smet wrote:
> There is a typo in the contrib part:
> # Add GIN support for hstore (Guillaume Smet, Teodor)
> # Add GIN support for pg_trgm (Guillaume Smet, Teodor0
>
> s/Teodor0/Teodor)/
>
> And I didn't participate to the GIN support of hstore, I just
On Thu, 2007-10-04 at 15:50 +0100, Simon Riggs wrote:
> On Thu, 2007-10-04 at 10:29 -0400, Tom Lane wrote:
> > Somebody who wants the
> > above behavior can send "ROLLBACK; DISCARD ALL".
>
> ...which generates an ERROR if no transaction is in progress and fills
> the log needlessly.
Well, it's a
On Mon, 2007-10-08 at 16:50 -0400, Alvaro Herrera wrote:
> palloc uses malloc underneath. My thought is to replace that with
> sbrk, mmap or something like that. Not very portable though, a lot of
> work, and most likely not nearly enough benefits.
Yeah, I agree this isn't likely to be a win in
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
> I think this almost says it all. My particular gripe about this whole
> thing is that there are other features that are not too intrusive (or
> appear so anyway) that are easily more useful that are not being
> considered at all. Namely,
On Thu, 2007-10-11 at 16:04 -0400, Bruce Momjian wrote:
> I have added the following introductory paragraph to the release notes:
>
> This release represents a major leap forward by adding significant new
> functionality and performance enhancements to
> PostgreSQL. Many complex
On Tue, 2007-10-16 at 11:24 +1000, Brendan Jurd wrote:
> Is there a technical reason we do not set the value of FOUND when
> executing a dynamic statement in plpgsql?
See prior discussion:
http://archives.postgresql.org/pgsql-bugs/2004-10/msg1.php
It would be easy enough to have EXECUTE
On Mon, 2007-10-22 at 15:40 +0200, Cédric Villemain wrote:
> Does postgresql use posix_fallocate ?
No.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL P
I noticed that processCancelRequest() emits a log message at DEBUG2 when
it receives a cancel request with a bad key or for a non-existent PID.
For example,
ereport(DEBUG2,
(errmsg_internal("bad key in cancel request for process %d",
backendPID)));
I think this ought
On Sun, 2007-11-04 at 11:06 -0500, Tom Lane wrote:
> No, if it's intended for the log it should be LOG. Your other proposals
> are actually *less* likely to get to where the DBA could see them.
Good point. I suggested WARNING because that suggests that something is
awry, whereas LOG is used for r
On Wed, 2007-11-07 at 11:38 +0900, Josh Berkus wrote:
> ./configure --with-libxml does not accept a location argument. This
> makes it impossible to configure 8.3 with LibXML on the Mac, because I
> can't upgrade the main libxml without breaking something, and
> ./configure doesn't let me speci
On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote:
> I expect these cleanups to continue for at least another week or two.
> Once they slow we will schedule RC1.
So are there no plans for an additional beta? Given the recent addition
of changes like
http://archives.postgresql.org/pgsql-comm
On Wed, 2007-11-28 at 09:38 -0800, Trevor Talbot wrote:
> PostgreSQL's problem is that it (and AFAICT POSIX) conflates encoding
> with locale, when the two are entirely separate concepts.
In what way does PostgreSQL conflate encoding with locale?
-Neil
---(end of broadc
On Tue, 2007-12-11 at 10:53 -0800, Josh Berkus wrote:
> Just so you don't lose sight of it, one of the biggest VLDB features we're
> missing is fault-tolerant bulk load.
I actually had to cook up a version of this for Truviso recently. I'll
take a look at submitting a cleaned-up implementation fo
On Thu, 2007-12-13 at 22:06 -0500, Tom Lane wrote:
> I guess that on purely philosophical grounds, it's not an unreasonable
> behavior. For example, "LIMIT n" means "output at most n tuples",
> not "output exactly n tuples". So when it outputs no tuples in the face
> of a negative limit, it's mee
On Fri, 2007-12-14 at 14:48 +0200, Hannu Krosing wrote:
> How did you do it ?
>
> Did you enchance COPY command or was it something completely new ?
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 ma
On Fri, 2007-12-14 at 18:22 -0500, Tom Lane wrote:
> If we could somehow only do a subtransaction per failure, things would
> be much better, but I don't see how.
One approach would be to essentially implement the pg_bulkloader
approach inside the backend. That is, begin by doing a subtransaction
On Fri, 2007-12-14 at 15:47 +, Gregory Stark wrote:
> I've wanted for a long time to have EXPLAIN ANALYZE output per-node I/O usage.
> This would be especially useful if we could distinguish hardware versus
> logical I/O though. And I always thought that would be very hard.
>
> My thought in t
On Tue, 2007-12-11 at 19:11 -0500, Greg Smith wrote:
> I'm curious what you feel is missing that pgloader doesn't fill that
> requirement: http://pgfoundry.org/projects/pgloader/
For complicated ETL, I agree that using an external tool makes the most
sense. But I think there is still merit in ad
In CVS HEAD, why does exec_simple_query() pass an empty cursorOptions to
pg_plan_queries() at postgres.c:903? If we're planning DECLARE CURSOR,
ISTM we ought to be passing down the DECLARE CURSOR's cursorOptions.
-Neil
---(end of broadcast)---
TIP
On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
> Maybe someone could enhance this concept to include it with the core
> database to provide autonomous transactions.
I agree that autonomous transactions would be useful, but doing them via
dblink is a kludge. If we're going to include anythi
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
> And there is most important question about data visibility - is
> autonomous transaction independent on main transaction (isolation)?
>From looking at how Oracle does them, autonomous transactions are
completely independent of the transacti
On Wed, 2008-01-23 at 09:30 +, Gregory Stark wrote:
> I think the hard part would be error handling. You have to be able to catch
> any errors and resume the outer transaction.
I agree that you'd need to do this, but I don't follow why it would be
particularly difficult. You essentially have a
I recently noticed that SQL:200n[1] defines a new aggregate function,
array_agg(). The relevant portions of the spec are:
p. 66: "If ARRAY_AGG is specified, then an array value with one element
formed from the evaluated for each row that
qualifies."
p. 556: ::=
ARRAY_AGG
[ ORDER BY ]
When building with MSVC 2005 (Express) and the Longhorn Platform SDK
(version 6.0a), it seems that IPPROTO_IPV6 is only defined when
_WIN32_WINNT >= 0x0501. This results in a compiler error when trying to
build pqcomm.c (line 389). According to [1], building for Windows 2000
(that is, _WIN32_WINNT
On Tue, 2008-01-29 at 13:06 +0100, Peter Eisentraut wrote:
> The ORDER BY clause would also used in XMLAGG, so we should try to parse this
> in a generalized way.
Yeah, that should be doable. We could go further and expose ORDER BY to
CREATE AGGREGATE, so that users could write aggregates that ar
On Mon, Sep 1, 2008 at 9:35 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> +1. I've been using a variation on this theme (it returns the type
> OID, not a text value) for a couple of years.
Returning regtype seems like the natural choice.
-Neil
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Tue, Sep 2, 2008 at 9:35 AM, David Fetter <[EMAIL PROTECTED]> wrote:
> Any chance we can buy a few copies of the official one for use on the
> project?
AFAIK there is no significant difference between the "official"
standard and the draft version available online, so I don't see the
point.
Nei
I noticed a minor leak in the per-query context when ExecReScanAgg()
is called for a hashed aggregate. During rescan, build_hash_table() is
called to create a new empty hash table in the aggcontext. However,
build_hash_table() also constructs the "hash_needed" column list in
the per-query context,
On Thu, Oct 16, 2008 at 5:26 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> It would probably be cleaner to take that logic out of build_hash_table
> altogether, and put it in a separate function to be called by
> ExecInitAgg.
Yeah, I considered that -- makes sense. Attached is the patch I
applied to H
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
> I am having trouble locating the previous thread - can someone please
> point me at it?
http://markmail.org/message/kyjbj5qovadfoe3w
-Neil
---(end of broadcast)---
TIP 7: You can help su
Consider this test case:
create table baz (a int, b int);
insert into baz (select 1, generate_series(1, 300));
select baz.*, (select 1 from generate_series(1, 1) g(a)
where g.a < baz.b)
from baz;
The final query consumes ~800 MB of memory on my syste
On Thu, 2008-02-21 at 21:42 -0500, Tom Lane wrote:
> Given your point (2), is this worth fixing by itself?
Right, probably not.
> Yeah. I think it's hopeless to expect these functions to all hew to
> the straight and narrow path. It seems to me that the right way is for
> the sub-select to some
On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote:
> As a result, I have a few questions about the timestamp code. In what
> instances is the floating point timestamp recommended?
One circumstance is when there isn't a native int64 type available. The
floating point datetime code is the tradi
On Tue, 2008-02-26 at 14:55 -0500, Tom Lane wrote:
> Anyway I think they both have their place.
I think it is very fragile to have the semantics of a builtin datatype
change depending on a configure option. It makes it difficult to write
applications that depend on the unique properties of *either
On Tue, 2008-02-26 at 11:33 -0800, Josh Berkus wrote:
> We need two (or more) PostgreSQL hackers to volunteer to regularly check the
> Coverity reports and either fix/forward the bugs found, or (more often) mark
> them as non-bugs in the Coverity system.
I take a look at this periodically. Appar
On Tue, 2008-02-26 at 14:57 -0800, Joshua D. Drake wrote:
> Would there be a way to script the responses to flag us for things
> that are important?
I think you need human verification / analysis, which isn't an easy
thing to script.
-Neil
---(end of broadcast)
On Wed, 2008-02-27 at 15:24 +0100, Pavel Stehule wrote:
> I thing RETURN QUERY is successful idea. It should be completed with
> support of dynamic SQL.
Yeah, I can see that being useful.
> RETURN EXECUTE sqlstring [USING];
What is the USING clause for?
-Neil
---(end
I notice that several of the call sites of tuplestore_puttuple() start
with arrays of datums and nulls, call heap_form_tuple(), and then switch
into the tstore's context and call tuplestore_puttuple(), which
deep-copies the HeapTuple into the tstore. ISTM it would be faster and
simpler to provide a
On Tue, 2008-03-11 at 20:56 +0800, longlong wrote:
> This would be a nice feature. Right now there are often applications
> where there is a data loading or staging table that ends up being
> merged with a larger table after some cleanup. Moving that data from
> the preperation area into the fina
On Tue, 2008-03-11 at 15:18 -0700, Neil Conway wrote:
> Note also that pg_bulkload currently does something analogous to this
> outside of the DBMS proper:
>
> http://pgbulkload.projects.postgresql.org/
Sorry, wrong project. I mean pgloader:
http://pgfoundry.org/projects/pglo
On Thu, 2008-03-20 at 20:05 -0300, Alvaro Herrera wrote:
> Neil, you're on the loop for changing the default in configure. Want to
> do the honors?
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
-Neil
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Sat, 2008-03-22 at 21:24 -0400, Tom Lane wrote:
> Oh, wait, that's just a -patches entry; it doesn't look like Neil
> ever committed it. Neil, how come?
Sorry, slipped through the cracks -- I've now committed the patch.
-Neil
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On Tue, 2008-03-25 at 17:26 -0300, Alvaro Herrera wrote:
> There is one hole here: contention on ProcArrayLock. Basically, for
> simple transactions we will need to update MyProc after every command.
If we're just updating MyProc->xmin, we only need to acquire
ProcArrayLock in shared mode, right?
1 - 100 of 1135 matches
Mail list logo
