I wrote:
> I started to wonder why the test in range_gist_consistent_int() for
> RANGESTRAT_CONTAINED_BY was "return true" (ie, search the entire index)
> rather than range_overlaps, which is what is tested in the comparable
> case in rtree_internal_consistent(). The regression tests showed me
> h
Andres Freund wrote:
> All current x86 cpus use 64bytes.
That matches what I found in recent research on the topic.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
> > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> >> I'd just as soon keep the fields in a logical order.
> >
> > Btw, I don't think the new order is necessarily wo
On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
> > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> >> I'd just as soon keep the fields in a logical order.
> >
> > Btw, I don't think the new order is necessarily wo
On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
> On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
>> I'd just as soon keep the fields in a logical order.
> Btw, I don't think the new order is necessarily worse than the old one.
You forget to attach the benchmark results.
My impr
On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> I'd just as soon keep the fields in a logical order.
Btw, I don't think the new order is necessarily worse than the old one.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> Andres Freund writes:
> > You could also try if it makes a difference reducing SnapshotData to one
> > instead of two cachelines. The data itself fits into one without
> > problems. Trivial patch attached.
> On what grounds do you argue
On 11/24/2011 06:29 AM, Lars Kanis wrote:
Isn't it better to check the value of macros itsef rather than checking for
system dependent macros that does not directly relate to the issue?
specifically for getaddrinfo.c case I think
#if EAI_NODATA != EAI_NONAME
is a better check than checking for
Andres Freund writes:
> You could also try if it makes a difference reducing SnapshotData to one
> instead of two cachelines. The data itself fits into one without problems.
> Trivial patch attached.
On what grounds do you argue that this patch gets SnapshotData into one
cacheline today (and on
Hi,
On Saturday, November 26, 2011 04:52:50 PM Pavan Deolasee wrote:
> I think now that we have reduced the run time of the function itself,
> we should now try to reduce the number of times the function is
> called. Robert proposed a way to reduce the number of calls per
> transaction. I think we
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near "foo"
but running
psql < foo.sql does not. I suggest we change the latter to print
psql::1: ERROR: syntax error at
On 10/12/2011 08:55 PM, Alex Hunsaker wrote:
On Wed, Oct 12, 2011 at 17:53, David E. Wheeler wrote:
On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also
Excerpts from Robert Haas's message of Thu Nov 24 13:57:17 +0200 2011:
>
> I think it would be really weird not to support user:pw@host:port. You can
> presumably also support the JDBC style for backward compatibility, but I
> don't think we should adopt that syntax as project standard.
By th
Hi,
Robert Haas writes:
> On Sun, Nov 13, 2011 at 8:57 PM, Robert Haas wrote:
>> In the -M extended case, we take a snapshot from exec_parse_message(),
>> and the same two in the exec_bind_message() call that are taken in the
>> -M prepared case. So reducing the prepared case from two snapshots
Excerpts from Robert Haas's message of Thu Nov 24 15:59:08 +0200 2011:
>
> I think we could do something like:
>
> postgresql://user:pw@host:port/database?param1=val1¶m2=val2¶m3=val3&...
I wonder if this should be allowed syntax (i.e. specify a user, but connect
locally, so leave 'host' to be
I started to wonder why the test in range_gist_consistent_int() for
RANGESTRAT_CONTAINED_BY was "return true" (ie, search the entire index)
rather than range_overlaps, which is what is tested in the comparable
case in rtree_internal_consistent(). The regression tests showed me
how come: an empty-r
Kohei KaiGai writes:
> We still don't have clear direction of the way to implement external
> permission
> checks on object creation time. So, please consider these patches are on the
> proof-of-concept stage; using prep-creation-hook to permission checks.
I wonder if you could implement that as
Excerpts from Peter Eisentraut's message of Thu Nov 24 22:05:09 +0200 2011:
>
> On tor, 2011-11-24 at 15:43 +0200, Alexander Shulgin wrote:
> > Huh? The service definitions are read from a local pg_service.conf,
> > and are specified by setting PGSERVICE (and PGSERVICEFILE) environment
> > varia
3 items are attached:
1. A spreadsheet, results.ods, which has results for automated
multiple runs of the "doubled up" dellstore orderlines queries (where
orderlines is 385 MB). Results are sorted, with the median (or the
lower middle value, didn't get the mean of the two middle runs) result
for e
Pavan Deolasee writes:
> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas wrote:
>> Furthermore, it's
>> hard to understand how this could be a net improvement in the general
>> case, because now both B and F are copying everything twice (once to
>> the shared area and one to backend-local memory) i
On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas wrote:
> On Sat, Nov 26, 2011 at 10:52 AM, Pavan Deolasee
> wrote:
>> What we can do is when a transaction comes to compute its snapshot, it
>> checks if some other transaction is already computing a snapshot for
>> itself. If so, it just sleeps on th
Bruce Momjian writes:
> Basically, if we keep the existing functions in common.c, we are
> deciding that it is never worth moving C functions to new C files for
> source code clarity. I was not sure we had made that decision in the
> past.
I once held hope that git would let us be more flexible
On 10/05/2011 03:58 AM, Amit Khandekar wrote:
On 5 October 2011 12:29, Alex Hunsaker wrote:
Find it attached. [ Note I didn't put the check inside the if (ret ==
utf8_str) as it seemed a bit cleaner (indentation wise) to have it
outside ]
I have no more issues with the patch.
Committed.
Tom Lane wrote:
> >> It is not possible to just link the old common.c into pg_restore and
> >> pg_dumpall because it contains calls to pg_dump-only functions.
> >>
> >> Ideas?
>
> > The only other idea I have is to keep most functions in the mis-named
> > common.c and move the memory functions in
On Sat, Nov 26, 2011 at 10:52 AM, Pavan Deolasee
wrote:
> What we can do is when a transaction comes to compute its snapshot, it
> checks if some other transaction is already computing a snapshot for
> itself. If so, it just sleeps on the lock. When the other process
> finishes computing the snaps
On 11-11-23 01:58 PM, Jan Urbański wrote:
On 20/11/11 19:14, Steve Singer wrote:
On 11-10-15 07:28 PM, Jan Urbański wrote:
Hi,
attached is a patch implementing the usage of SPI cursors in PL/Python.
Currently when trying to process a large table in PL/Python you have
slurp it all into memory (
On 11/20/2011 11:07 AM, Josh Kupershmidt wrote:
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan wrote:
Updated patch is attached - adding to Nov commitfest.
Review of the v2 patch:
* Submission Review
Patch applies with some fuzz and builds without warnings. I noticed
some tab characters bei
Bruce Momjian writes:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>>> object to arbitrarily moving a bunch of longstanding code from one file
>>> to another. What that is mainly going to accomplish is creating a big
>>> headache whenever we have to back-patch fixes that touch that code
>>> ... and
On some recent benchmarks and profile data, I saw GetSnapshotData
figures at the very top or near top. For lesser number of clients, it
can account for 10-20% of time, but more number of clients I have seen
it taking up as much as 40% of sample time. Unfortunately, the machine
of which I was runnin
Peter Eisentraut writes:
> On fre, 2011-11-18 at 09:44 -0500, Tom Lane wrote:
>> It wouldn't be that hard for elog.c to do strrchr(fname, '/') or
>> something like that,
> Here is a patch for that. I would also like to backpatch this.
Hmmm ... is it possible that strrchr could change errno? If
Dne 25.11.2011 17:48, Tom Lane napsal(a):
> "Tomas Vondra" writes:
>> On 25 Listopad 2011, 2:44, Robert Haas wrote:
>>> I've thought of this before, but I'm not exactly clear on what the use
>>> cases are.
>
>> The startup hook is useful for initializing an extension written in C,
>> when the ext
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, Nov 21, 2011 at 2:30 PM, Bruce Momjian wrote:
> > > Robert Haas wrote:
> > >> On Mon, Nov 21, 2011 at 1:05 PM, Bruce Momjian wrote:
> > >> > Robert Haas wrote:
> > >> >> Argh. ?The root of the problem here seems to be that
> > >> >> join_path_
On fre, 2011-11-18 at 09:44 -0500, Tom Lane wrote:
> It wouldn't be that hard for elog.c to do strrchr(fname, '/') or
> something like that,
Here is a patch for that. I would also like to backpatch this.
diff --git i/src/backend/utils/error/elog.c w/src/backend/utils/error/elog.c
index 9a99fc7..
On 25.11.2011 23:32, Jeff Janes wrote:
On Fri, Nov 25, 2011 at 12:53 PM, Jeff Janes wrote:
Thanks for this patch. Doing bulk copies in parallel for me is now
limited by the IO subsystem rather than the CPU.
This patch, commit number d326d9e8ea1d69, causes fillfactor to be
ignored for the cop
34 matches
Mail list logo
