On Thu, Feb 2, 2012 at 2:32 AM, Magnus Hagander wrote:
>
> I haven't looked through the code in detail, but one direct comment:
> do we really need/want to send this through the stats collector? It
> will only ever have one sender - perhaps we should just either store
> it in shared memory or stor
On Wed, Jan 25, 2012 at 9:47 PM, Noah Misch wrote:
>
> With all that done, run some quick benchmarks: see how "SELECT free_percent
> FROM pgstattuple(rel)" fares compared to "SELECT relation_free_space(rel)" for
> a large heap and for a large B-tree index. If the timing difference is too
> small
(2012/02/13 20:50), Etsuro Fujita wrote:
> The patches have been applied, but role-related regression tests failed
> in my environment. I fixed it in a similar fashion of
> /src/test/regress/sql/foreign_data.sql. Please find attached a updated
> patch for the regression tests.
Good catch, thanks
On Mon, Feb 13, 2012 at 7:51 AM, Kohei KaiGai wrote:
> I rebased the patch due to the updates of pg_proc.h.
>
> Please see the newer one. Thanks,
Thanks, committed. I think, though, that some further adjustment is
needed here, because you currently can't do ALTER FUNCTION ... NO
LEAKPROOF, which
Looking over the SSI 2PC code recently, I noticed that I overlooked a
case that could lead to non-serializable behavior after a crash.
When we PREPARE a serializable transaction, we store part of the
SERIALIZABLEXACT in the statefile (in addition to the list of SIREAD
locks). One of the pieces of
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > Instead of or in addition to a fixed number operations per test, maybe
> > we should cut off each test after a certain amount of wall-clock time,
> > like 15 seconds.
>
> +1, I was about to suggest the same thing.
Robert Haas writes:
> Instead of or in addition to a fixed number operations per test, maybe
> we should cut off each test after a certain amount of wall-clock time,
> like 15 seconds.
+1, I was about to suggest the same thing. Running any of these tests
for a fixed number of iterations will res
On Mon, Feb 13, 2012 at 7:42 PM, Bruce Momjian wrote:
> I have heard complaints that /contrib/pg_test_fsync is too slow. I
> thought it was impossible to speed up pg_test_fsync without reducing its
> accuracy.
>
> However, now that I some consumer-grade SATA 2 drives, I noticed that
> the slownes
I have heard complaints that /contrib/pg_test_fsync is too slow. I
thought it was impossible to speed up pg_test_fsync without reducing its
accuracy.
However, now that I some consumer-grade SATA 2 drives, I noticed that
the slowness is really in the open_sync test:
Compare open_sync with
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 12/02/12 00:48, Tom Lane wrote:
>> What's more, it's unclear that
>> it won't malfunction altogether if the function is used recursively
>> (ie, what if PLyDict_FromTuple ends up calling the same function again?)
> I was a bit worried about that, but
On Tue, Feb 07, 2012 at 04:44:09PM +0200, Marko Kreen wrote:
> Although it seems we could allow exceptions, at least when we are
> speaking of Postgres backend, as the connection and result are
> internally consistent state when the handler is called, and the
> partial PGresult is stored under PGco
On Feb 13, 2012 7:49 p.m., "Greg Stark" wrote:
>
> I don't think we should be looking at either CUDA or OpenCL directly.
> We should be looking for a generic library that can target either and
> is well maintained and actively developed. Any GPU code we write
> ourselves would rapidly be overtaken
On 12/02/12 00:48, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> This is annoying for functions that plough through large tables, doing
>> some calculation. Attached is a patch that does the conversion of
>> PostgreSQL Datums into Python dict objects in a scratch memory context
>>
On fre, 2012-02-10 at 01:24 -0500, Tom Lane wrote:
> That seems pretty nearly entirely bogus. What is the argument for
> supposing that the word right after SELECT is a function name? I would
> think it would be a column name (from who-knows-what table) much more
> often.
That's what the patch d
On tor, 2012-02-09 at 23:02 +0100, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
> > Make tab-completion complete also function names – like: SELECT
> > pg_get to see all functions that start with pg_get.
> >
> > Make tab-completion work for columns in SELECT. I know that when writing
> > SEL
Robert Haas wrote:
On Mon, Feb 13, 2012 at 7:45 AM, Robert Haas wrote:
On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt wrote:
So my pre-built 9.1.2 takes 434s, my source-built 9.2 takes 509s, and
(probably both of our) 9.1-HEAD takes 1918s... is that something to worry
about, and if so, are there
Robert Haas wrote:
> Kevin Grittner wrote:
>> Well, personally I have a hard time calling READ COMMITTED
>> behavior sensible. Consider this:
>>
>> [ gigantic pile of fail ]
>
> Yeah, that's bad all right. I think it's hard to argue that the
> current behavior is sensible; the trick is to fig
On 02/13/2012 11:00 AM, Tom Lane wrote:
Robert Haas writes:
On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan
wrote:
Do we actually need to bother with these cases?
In flatten_join_alias_vars_mutator(), we've got a RangeTblEntry to
work with. I think the column names are to be found in th
On 02/13/2012 01:33 PM, Andrew Dunstan wrote:
On 02/13/2012 12:48 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/13/2012 11:15 AM, Tom Lane wrote:
After looking a bit more at the existing explain code, it seems
like the
critical issue is that explain.c has
ExplainOpenGroup/ExplainClose
I don't think we should be looking at either CUDA or OpenCL directly.
We should be looking for a generic library that can target either and
is well maintained and actively developed. Any GPU code we write
ourselves would rapidly be overtaken by changes in the hardware and
innovations in parallel al
On 02/13/2012 12:48 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/13/2012 11:15 AM, Tom Lane wrote:
After looking a bit more at the existing explain code, it seems like the
critical issue is that explain.c has ExplainOpenGroup/ExplainCloseGroup
calls around the ExplainPrintPlan call (see
On Mon, Feb 13, 2012 at 10:48 AM, Kevin Grittner
wrote:
> Well, personally I have a hard time calling READ COMMITTED behavior
> sensible. Consider this:
>
> [ gigantic pile of fail ]
Yeah, that's bad all right. I think it's hard to argue that the
current behavior is sensible; the trick is to fi
Andrew Dunstan writes:
> On 02/13/2012 11:15 AM, Tom Lane wrote:
>> After looking a bit more at the existing explain code, it seems like the
>> critical issue is that explain.c has ExplainOpenGroup/ExplainCloseGroup
>> calls around the ExplainPrintPlan call (see ExplainOnePlan), while
>> auto_expl
On 02/13/2012 11:15 AM, Tom Lane wrote:
[ sorry for ignoring this over the weekend --- I wasn't feeling very well ]
Andrew Dunstan writes:
On 02/11/2012 03:22 PM, Tom Lane wrote:
I'm inclined to think that this is auto_explain's error, not that of
the core code, ie we should be changing the
On Feb 13, 2012, at 9:30 AM, Pavel Stehule wrote:
> no in stable
>
> http://www.depesz.com/2011/07/20/waiting-for-9-2-stacked-diagnostics-in-plpgsql/
Ah, great, I had forgotten about that.
Thank you,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Feb 13, 2012 11:39 a.m., "Kohei KaiGai" wrote:
>
> 2012/2/13 Greg Smith :
> > On 02/11/2012 08:14 PM, Gaetano Mendola wrote:
> >>
> >> The trend is to have server capable of running CUDA providing GPU via
> >> external hardware (PCI Express interface with PCI Express switches),
look
> >> for ex
Hello
2012/2/13 David E. Wheeler :
> Hackers,
>
> In PL/pgSQL exception handling, I'm able to access the error code (SQLSTATE)
> and error message (SQLERRM). Is there any way to get at error details (yet)?
> If not, could SQLDETAIL or some such be added?
>
no in stable
http://www.depesz.com/20
Hackers,
In PL/pgSQL exception handling, I'm able to access the error code (SQLSTATE)
and error message (SQLERRM). Is there any way to get at error details (yet)? If
not, could SQLDETAIL or some such be added?
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Mon, Feb 13, 2012 at 8:37 PM, Heikki Linnakangas
wrote:
> On 13.02.2012 01:04, Jeff Janes wrote:
>>
>> Attached is my quick and dirty attempt to set XLP_FIRST_IS_CONTRECORD.
>> I have no idea if I did it correctly, in particular if calling
>> GetXLogBuffer(CurrPos) twice is OK or if GetXLogBuf
[ sorry for ignoring this over the weekend --- I wasn't feeling very well ]
Andrew Dunstan writes:
> On 02/11/2012 03:22 PM, Tom Lane wrote:
>> I'm inclined to think that this is auto_explain's error, not that of
>> the core code, ie we should be changing the output.
> Well, maybe this is more t
Robert Haas writes:
> On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan
> wrote:
>> Do we actually need to bother with these cases?
> In flatten_join_alias_vars_mutator(), we've got a RangeTblEntry to
> work with. I think the column names are to be found in the alias
> and/or eref attributes of
Robert Haas wrote:
> The example that I remember was related to SELECT FOR
> UPDATE/SELECT FOR SHARE. The idea of those statements is that you
> want to prevent the row from being updated or deleted until some
> other concurrent action is complete; for example, in the case of a
> foreign key, w
On Mon, Feb 13, 2012 at 11:02, Chetan Suttraway <
chetan.suttra...@enterprisedb.com> wrote:
> The patch was not getting applied. Was seeing below message:
> postgresql$ git apply /Downloads/unchanged.patch
> error: src/backend/utils/adt/ri_triggers.c: already exists in working
> directory
>
> Hav
Robert Haas writes:
> Another option might be to store all the sequences for a particular
> database in a single underlying data file.
We've looked into that before, and found some roadblocks IIRC, though
it probably isn't completely infeasible. See the archives.
regards
On Mon, Feb 13, 2012 at 15:25, Robert Haas wrote:
> On Sat, Feb 11, 2012 at 9:06 PM, Vik Reykja wrote:
> > I decided to take a crack at the todo item created from the following
> post:
> > http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php
> >
> > The attached patch makes the
On Mon, Feb 13, 2012 at 9:41 AM, Andres Freund wrote:
> On Monday, February 13, 2012 02:08:08 PM Robert Haas wrote:
>> On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs wrote:
>> > Yeh, I was thinking we would do well to implement cached sequences for
>> > say first 1000 sequences.
>>
>> Another optio
On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan
wrote:
Other candidates I have found that don't set colnames and should
probably use dummy names are:
* src/backend/parser/gram.y (row: production)
*
src/backend/optimizer/prep/prepunion.c:adjust_appendrel_attrs_mutator(
On Monday, February 13, 2012 02:08:08 PM Robert Haas wrote:
> On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs wrote:
> > Yeh, I was thinking we would do well to implement cached sequences for
> > say first 1000 sequences.
>
> Another option might be to store all the sequences for a particular
> data
On Fri, Feb 10, 2012 at 11:46 PM, Noah Misch wrote:
> On Fri, Feb 10, 2012 at 01:59:18PM -0500, Robert Haas wrote:
>> On Fri, Feb 10, 2012 at 6:42 AM, Noah Misch wrote:
>> > I like the design you have chosen. ?It would find applications beyond
>> > TRUNCATE, so your use of non-specific naming is
On Sat, Feb 11, 2012 at 7:16 AM, Jesper Krogh wrote:
> Ok, but there are still cases where we don't even need to construct
> a data tuple at all:
>
> 2012-02-11 13:14:01.579 jk=# explain select count(*) from testtable where
> fts @@ to_tsquery('english','test1');
> Q
On Sat, Feb 11, 2012 at 9:06 PM, Vik Reykja wrote:
> I decided to take a crack at the todo item created from the following post:
> http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php
>
> The attached patch makes the desired changes in both code and function
> naming.
>
> It seeme
On Mon, Feb 13, 2012 at 8:51 AM, Marti Raudsepp wrote:
> On Mon, Feb 13, 2012 at 15:08, Robert Haas wrote:
>> Honestly, I think the biggest hassle of the OID code is not so much
>> the way they're generated as the way they're stored within heap
>> tuples. I've wondered whether we should go throu
On Mon, Feb 13, 2012 at 15:08, Robert Haas wrote:
> Honestly, I think the biggest hassle of the OID code is not so much
> the way they're generated as the way they're stored within heap
> tuples. I've wondered whether we should go through the system
> catalogs and replace all of the hidden OID co
On Mon, Feb 13, 2012 at 7:45 AM, Robert Haas wrote:
> On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt wrote:
>> So my pre-built 9.1.2 takes 434s, my source-built 9.2 takes 509s, and
>> (probably both of our) 9.1-HEAD takes 1918s... is that something to worry
>> about, and if so, are there any tests I
On Fri, Feb 10, 2012 at 3:57 PM, Peter Eisentraut wrote:
> On sön, 2012-02-05 at 10:53 -0800, Jeff Davis wrote:
>> > initdb should do these syncs by default and offer an option to
>> disable them.
>>
>> For test frameworks that run initdb often, that makes sense.
>>
>> But for developers, it doesn
On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs wrote:
> Yeh, I was thinking we would do well to implement cached sequences for
> say first 1000 sequences.
Another option might be to store all the sequences for a particular
database in a single underlying data file. The current implementation
uses
On Thu, Feb 9, 2012 at 3:37 PM, Jay Levitt wrote:
> So my pre-built 9.1.2 takes 434s, my source-built 9.2 takes 509s, and
> (probably both of our) 9.1-HEAD takes 1918s... is that something to worry
> about, and if so, are there any tests I can run to assist? That bug doesn't
> affect me personally
Re: Alex Hunsaker 2012-02-10
> Does the attached fix the issue for you?
Yes. :)
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
signature.asc
Description: Digital signature
(2012/02/10 20:39), Shigeru Hanada wrote:
> (2012/02/08 20:51), Shigeru Hanada wrote:
>> Attached revised patches. Changes from last version are below.
>
>
> I've found and fixed a bug which generates wrong remote query when any
> column of a foreign table has been dropped. Also regression test
> Because connect_timeout is a separate libpq connection parameter, but
> now it's stuck into "options". It might have worked more or less by
> accident before.
So it is not an option, right? But the old function accepted it as an option it
seems.
> It's not clear to me why this only appears on
Hi,
Sorry for the delays, I'm back on PostgreSQL related work again.
Hitoshi Harada writes:
>>> I just tried DROP EXTENSION now, and found it broken :(
Please find v2 of the patch. I did change the dependency management in
between the simple cases and the more challenging ones and forgot that
2012/2/13 Greg Smith :
> On 02/11/2012 08:14 PM, Gaetano Mendola wrote:
>>
>> The trend is to have server capable of running CUDA providing GPU via
>> external hardware (PCI Express interface with PCI Express switches), look
>> for example at PowerEdge C410x PCIe Expansion Chassis from DELL.
>
>
>
On Sat, Feb 11, 2012 at 01:54, Gaetano Mendola wrote:
> I wonder if somewhere in Postgres source "we" are relying on the GCC
> "correct behaviour" regarding the read-modify-write of bitfield in
> structures.
Probably not. I'm pretty sure that we don't have any bitfields, since
not all compilers a
On Sun, Feb 12, 2012 at 7:36 AM, Vik Reykja wrote:
> I decided to take a crack at the todo item created from the following post:
> http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php
>
> The attached patch makes the desired changes in both code and function
> naming.
>
> It seem
>> Without sorted checkpoints (or some other fancier method) you have to
>> write out the entire pool before you can do any fsyncs. Or you have
>> to do multiple fsyncs of the same file, with at least one occurring
>> after the entire pool was written. With a sorted checkpoint, you can
>> start i
Dan, I believe your approach of double buffer write is right as it has
potential that it can avoid the latency backends incur during full page writes
after checkpoint. Although there are chances that overall I/O will be more in
this case but if we can make sure that in most scenarios backend has
56 matches
Mail list logo
