On 05/16/2014 08:06 AM, Blagoj Petrushev wrote:
> Hi,
>
> I'm thinking of an extension to trigger functionality like this:
>
> CREATE TRIGGER trigger_name
> AFTER event
> ON table
> CONCURRENTLY EXECUTE PROCEDURE trigger_fc
>
> This would call the trigger after the end of the transac
Hi all
There's a bug in the dynamic bgworkers code that I think needs fixing
before release. TL;DR: BGW_NO_RESTART workers are restarted after
postmaster crash, attached patch changes that.
The case that's triggering the issue is where a static bgworker is
registering a new dynamic bgworker to do
Hi all,
Are there some reason to don't show the tablespace size in the \db+ psql
command?
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/f
I wrote:
> Yeah. This is caused by a hyperlink whose displayed text crosses a page
> boundary. The only known fix is to change the text enough so the link
> no longer runs across a page boundary. Unfortunately, pdfTeX is pretty
> unhelpful about identifying exactly where the problem is. I seem
Peter Eisentraut writes:
> Mysteriously, commit 6b2a1445ec8a631060c4cbff3f172bf31d3379b9 has broken
> the PDF build (openjade + pdfjadetex) in the 9.0 branch only. The error
> is
> [256.0.28
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than
> \pd
> fstartlink.
Oh, n
Mysteriously, commit 6b2a1445ec8a631060c4cbff3f172bf31d3379b9 has broken
the PDF build (openjade + pdfjadetex) in the 9.0 branch only. The error
is
[256.0.28
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
fstartlink.
\AtBegShi@Output ...ipout \box \AtBeginShipoutB
Blagoj Petrushev wrote
> Hi,
>
> I'm thinking of an extension to trigger functionality like this:
>
> CREATE TRIGGER trigger_name
> AFTER event
> ON table
> CONCURRENTLY EXECUTE PROCEDURE trigger_fc
>
> This would call the trigger after the end of the transaction.
>
> The following
Andres Freund-3 wrote
> On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
>> I have completed the initial version of the 9.4 release notes. You can
>> view them here:
>>
>> http://www.postgresql.org/docs/devel/static/release-9-4.html
>>
>> I will be adding additional markup in the next few
Andrew Dunstan wrote
> On 05/15/2014 06:37 PM, Rohit Goyal wrote:
>> Hi All,
>>
>> I am using centOS6 and after all confugration, I run the below command
>>
>> *dbt2-run-workload -a pgsql -d 120 -w 1 -o /tmp/result -c 10
>> *
>> *Error:*
>> Stage 3. Processing of results...
>> Killing client...
>>
On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected
Hi,
I'm thinking of an extension to trigger functionality like this:
CREATE TRIGGER trigger_name
AFTER event
ON table
CONCURRENTLY EXECUTE PROCEDURE trigger_fc
This would call the trigger after the end of the transaction.
The following is a use-case, please tell me if I'm doing it w
On 15.5.2014 22:07, Andrew Dunstan wrote:
>
> Yes, I've seen that. Frankly, a test that takes something like 500
> hours is a bit crazy.
Maybe. It certainly is not a test people will use during development.
But if it can detect some hard-to-find errors in the code, that might
possibly lead to se
On 15.5.2014 22:56, Andrew Dunstan wrote:
>
> On 05/15/2014 04:30 PM, Stefan Kaltenbrunner wrote:
>
>> well I'm not sure about about "misconfigured" but both my personal
>> buildfarm members and pginfra run ones (like gaibasaurus) got errors
>> complaining about "snapshot too old" in the past for
On Thu, May 15, 2014 at 3:47 PM, Andrew Dunstan wrote:
> Do these questions about running dbt2 even belong on pgsql-hackers? They
> seem to me to be usage questions that belong on pgsql-general.
I agree.
Anyway, perhaps the OP will have more luck with OLTPBenchmark, which
has some kind of TPC-C
On 05/15/2014 06:37 PM, Rohit Goyal wrote:
Hi All,
I am using centOS6 and after all confugration, I run the below command
*dbt2-run-workload -a pgsql -d 120 -w 1 -o /tmp/result -c 10
*
*Error:*
Stage 3. Processing of results...
Killing client...
waiting for server to shut down done
server
Hi All,
I am using centOS6 and after all confugration, I run the below command
*dbt2-run-workload -a pgsql -d 120 -w 1 -o /tmp/result -c 10*
*Error:*
Stage 3. Processing of results...
Killing client...
waiting for server to shut down done
server stopped
Traceback (most recent call last):
F
On Thu, May 15, 2014 at 4:50 PM, David G Johnston
wrote:
> Jon Nelson-14 wrote
>> I was watching a very large recursive CTE get built today and this CTE
>> involves on the order of a dozen or so "loops" joining the initial
>> table against existing tables. It struck me that - every time through
>>
Sorry, I've forgotten the report.
The test fails on label test come from specification change in the mcs policy.
Previously, it was applied to all the domains including unconfined_t, but now,
it became to be applied on the domain with "mcsconstrained" attribute.
This regression test run sepgsql_s
Andres Freund wrote:
> On 2014-05-15 17:37:14 -0400, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > On 2014-05-15 15:40:06 -0400, Robert Haas wrote:
> > > > On Thu, May 15, 2014 at 2:34 PM, Bruce Momjian wrote:
> >
> > > > If the larger clog size is a show-stopper (and I'm not sure I have a
On 2014-05-15 18:52:45 -0300, Euler Taveira wrote:
> On 15-05-2014 18:09, Andres Freund wrote:
> > I have some preliminary tests for the pg_recvlogical binary using the
> > infrastructure Peter added. I am wondering if somebody has a good idea
> > about how to make the tests more meaningful. Curren
On 15-05-2014 18:09, Andres Freund wrote:
> I have some preliminary tests for the pg_recvlogical binary using the
> infrastructure Peter added. I am wondering if somebody has a good idea
> about how to make the tests more meaningful. Currently all that's tested
> are simple commands. Not the main f
Jon Nelson-14 wrote
> I was watching a very large recursive CTE get built today and this CTE
> involves on the order of a dozen or so "loops" joining the initial
> table against existing tables. It struck me that - every time through
> the loop the tables were sorted and then joined and that it wou
On Wed, May 14, 2014 at 8:26 AM, Robert Haas wrote:
> On Sun, May 11, 2014 at 12:47 PM, Tom Lane wrote:
> > Simon Riggs writes:
> >> On 11 May 2014 11:18, Andres Freund wrote:
> >>> I don't know. I'd find UPDATE/DELETE ORDER BY something rather
> >>> useful.
> >
> >> Perhaps if an index exists
On 2014-05-15 17:37:14 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2014-05-15 15:40:06 -0400, Robert Haas wrote:
> > > On Thu, May 15, 2014 at 2:34 PM, Bruce Momjian wrote:
>
> > > If the larger clog size is a show-stopper (and I'm not sure I have an
> > > intelligent opinion on th
Andres Freund wrote:
> On 2014-05-15 15:40:06 -0400, Robert Haas wrote:
> > On Thu, May 15, 2014 at 2:34 PM, Bruce Momjian wrote:
> > If the larger clog size is a show-stopper (and I'm not sure I have an
> > intelligent opinion on that just yet), one way to get around the
> > problem would be to
I was watching a very large recursive CTE get built today and this CTE
involves on the order of a dozen or so "loops" joining the initial
table against existing tables. It struck me that - every time through
the loop the tables were sorted and then joined and that it would be
much more efficient if
Hi,
I have some preliminary tests for the pg_recvlogical binary using the
infrastructure Peter added. I am wondering if somebody has a good idea
about how to make the tests more meaningful. Currently all that's tested
are simple commands. Not the main functionality namely the actual
streaming of c
On 2014-05-15 22:30:53 +0300, Heikki Linnakangas wrote:
> >Attached patch fixes things, but I want to add some regression tests
> >before commit.
>
> Looks good to me.
Attached are two patches. One for the unitialized dbId/tsId issue; one
for the decoding bug. The former should be backpatched.
Sh
On 05/15/2014 04:30 PM, Stefan Kaltenbrunner wrote:
On 05/15/2014 07:46 PM, Andrew Dunstan wrote:
On 05/15/2014 12:43 PM, Tomas Vondra wrote:
Hi all,
today I got a few of errors like these (this one is from last week,
though):
Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014
On 05/15/2014 07:46 PM, Andrew Dunstan wrote:
>
> On 05/15/2014 12:43 PM, Tomas Vondra wrote:
>> Hi all,
>>
>> today I got a few of errors like these (this one is from last week,
>> though):
>>
>> Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
>> Content:
>> snapshot t
On 2014-05-15 16:13:49 -0400, Bruce Momjian wrote:
> On Thu, May 15, 2014 at 10:06:32PM +0200, Andres Freund wrote:
> > > If the larger clog size is a show-stopper (and I'm not sure I have an
> > > intelligent opinion on that just yet), one way to get around the
> > > problem would be to summarize
Andrew Dunstan writes:
> Incidentally, should the CLOBBER_CACHE_ALWAYS machines also be defining
> CLOBBER_FREED_MEMORY?
The former does need the latter or it's not very thorough. However,
CLOBBER_FREED_MEMORY is defined automatically by --enable-cassert,
so you shouldn't need to use a -D switc
On Thu, May 15, 2014 at 10:06:32PM +0200, Andres Freund wrote:
> > If the larger clog size is a show-stopper (and I'm not sure I have an
> > intelligent opinion on that just yet), one way to get around the
> > problem would be to summarize CLOG entries after-the-fact. Once an
> > XID precedes the
On 05/15/2014 03:57 PM, Tomas Vondra wrote:
How long does a CLOBBER_CACHE_RECURSIVELY run take? days or weeks seems
kinda nuts.
I don't know. According to this comment from cache/inval.c, it's expected
to be way slower (~100x) compared to CLOBBER_CACHE_ALWAYS.
/*
* Test code to force cache f
On 2014-05-15 15:40:06 -0400, Robert Haas wrote:
> On Thu, May 15, 2014 at 2:34 PM, Bruce Momjian wrote:
> > On Mon, May 12, 2014 at 06:01:59PM +0300, Heikki Linnakangas wrote:
> >> >Some of the stuff in here will be influence whether your freezing
> >> >replacement patch gets in. Do you plan to f
On 2014-05-15 22:30:53 +0300, Heikki Linnakangas wrote:
> On 05/15/2014 08:46 PM, Andres Freund wrote:
> >On 2014-05-15 20:07:23 +0300, Heikki Linnakangas wrote:
> >How very wierd. The reason for this is that
> >RecordTransactionCommitPrepared() forgets to fill a couple of fields in
> >xl_xact_comm
On 15 Květen 2014, 19:46, Andrew Dunstan wrote:
>
> On 05/15/2014 12:43 PM, Tomas Vondra wrote:
>> Hi all,
>>
>> today I got a few of errors like these (this one is from last week,
>> though):
>>
>> Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
>> Content:
>> snapshot
Andres Freund anarazel.de> writes:
>
> Hi,
>
> Some comments about the patch:
> * Coding Style:
> * multiline comments have both /* and */ on their own lines.
> * I think several places indent by two tabs.
> * Spaces around operators
> * ...
> * Many of the new comments would enjoy a bi
Jeff Janes wrote:
> If you have a database with a large table in it that has just passed
> autovacuum_freeze_max_age, all future workers will be funnelled into that
> database until the wrap-around completes. But only one of those workers
> can actually vacuum the one table which is holding back
On Thu, May 15, 2014 at 2:34 PM, Bruce Momjian wrote:
> On Mon, May 12, 2014 at 06:01:59PM +0300, Heikki Linnakangas wrote:
>> >Some of the stuff in here will be influence whether your freezing
>> >replacement patch gets in. Do you plan to further pursue that one?
>>
>> Not sure. I got to the poin
On 05/15/2014 08:46 PM, Andres Freund wrote:
On 2014-05-15 20:07:23 +0300, Heikki Linnakangas wrote:
Ok, so the immediate cause was quick to find: when decoding a
commit-prepared WAL record, we have to use the XID from the record content
(patch attached). The XID in the record header is the XID
On Thu, May 15, 2014 at 02:47:21PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 12, 2014 at 07:16:48PM -0400, Tom Lane wrote:
> >> I agree, that seems an entirely gratuitous choice of zone. It does
> >> seem like a good idea to test a zone that has a nonintegral offset
> >> from
In testing 9.4 with some long running tests, I noticed that autovacuum
launcher/worker sometimes goes a bit nuts. It vacuums the same database
repeatedly without respect to the nap time.
As far as I can tell, the behavior is the same in older versions, but I
haven't tested that.
This is my under
On Thu, May 15, 2014 at 10:38 AM, Andres Freund wrote:
>> . async.c and namespace.c does the same, and it hasn't been a
>> problem.
>
> Well, it doesn't seem unreasonable to have C code using
> PG_ENSURE_ERROR_CLEANUP/PG_END_ENSURE_ERROR_CLEANUP around a 2pc commit
> to me. That'll break with this
On Thu, May 15, 2014 at 8:06 AM, Bruce Momjian wrote:
> On Tue, May 6, 2014 at 11:15:17PM +0100, Simon Riggs wrote:
>> > Well, for what it's worth, I've encountered systems where setting
>> > effective_cache_size too low resulted in bad query plans, but I've
>> > never encountered the reverse sit
On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote:
> A recent question from Tim Kane prompted me to measure the overhead
> costs of EXPLAIN ANALYZE, which I'd not checked in awhile. Things
> are far worse than I thought. On my current server (by no means
> lavish hardware: Xeon E5-2609 @2.
On Tue, May 13, 2014 at 09:55:26AM -0400, Alvaro Herrera wrote:
> Christoph Berg wrote:
>
> > Of course, Wikipedia has something to say about this:
> > http://en.wikipedia.org/wiki/Timekeeping_on_Mars
>
> Nice.
>
> > I especially like MTC, Mars Time Coordinated. But whatever scheme gets
> > chos
Bruce Momjian writes:
> On Mon, May 12, 2014 at 07:16:48PM -0400, Tom Lane wrote:
>> I agree, that seems an entirely gratuitous choice of zone. It does
>> seem like a good idea to test a zone that has a nonintegral offset
>> from GMT, but we can get that from almost anywhere as long as we're
>> t
On Wed, May 14, 2014 at 8:46 PM, Jeff Janes wrote:
>> +1. I can't think of many things we might do that would be more
>> important.
>
> Can anyone guess how likely this approach is to make it into 9.5? I've been
> pondering some incremental improvements over what we have now, but if this
> revol
On Mon, May 12, 2014 at 07:16:48PM -0400, Tom Lane wrote:
> Christoph Berg writes:
> > 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp
> > constructors. In the regression tests, various time zones are tested,
> > including America/Metlakatla. Now, if you configure using
> > --with-sy
On Mon, May 12, 2014 at 06:01:59PM +0300, Heikki Linnakangas wrote:
> >Some of the stuff in here will be influence whether your freezing
> >replacement patch gets in. Do you plan to further pursue that one?
>
> Not sure. I got to the point where it seemed to work, but I got a
> bit of a cold feet
Now that popen and pclose don't throw thousands of warnings when compiling
mingw builds, some other warnings stand out.
parallel.c: In function 'pgpipe':
parallel.c:1332:2: warning: overflow in implicit constant conversion
[-Woverflow]
parallel.c:1386:3: warning: overflow in implicit constant con
Hello
2014-05-15 15:04 GMT+02:00 Sergey Muraviov :
> Hi.
> Please review the new patch.
>
This version works perfect
Regards
Pavel
>
> PS
> Issues which were described by Tom and Pavel were relevant to single-line
> headers.
> So I've added appropriate regression tests to the patch.
>
> I'v
On 2014-05-15 19:46:57 +0200, Andres Freund wrote:
> Attached patch fixes things, but I want to add some regression tests
> before commit.
And now actually attached. Will send a patch with regression tests later
tonight or tomorrow. Need to eat first...
Greetings,
Andres Freund
--
Andres Freu
On 2014-05-15 20:07:23 +0300, Heikki Linnakangas wrote:
> Ok, so the immediate cause was quick to find: when decoding a
> commit-prepared WAL record, we have to use the XID from the record content
> (patch attached). The XID in the record header is the XID of the transaction
> doing the COMMIT PREP
On 05/15/2014 12:43 PM, Tomas Vondra wrote:
Hi all,
today I got a few of errors like these (this one is from last week, though):
Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
Content:
snapshot to old: Wed May 7 04:36:57 2014 GMT
on the new buildfarm animals. I b
Hi,
On 2014-05-15 20:07:23 +0300, Heikki Linnakangas wrote:
> On 05/15/2014 07:57 PM, Heikki Linnakangas wrote:
> >Spotted while testing pg_recvlogical:
> >
> >1. Set up pg_recvlogical to receive:
> >
> >./pg_recvlogical -S fooslot -d postgres --create
> >./pg_recvlogical -S fooslot -d postgres --
On 05/15/2014 07:59 PM, Andres Freund wrote:
On 2014-05-13 17:43:47 +0300, Heikki Linnakangas wrote:
On 05/13/2014 04:35 PM, Andres Freund wrote:
On 2014-05-13 16:31:25 +0300, Heikki Linnakangas wrote:
Another thing I noticed is that if when the output goes to a file, the file
isn't re-opened
On 05/15/2014 07:57 PM, Heikki Linnakangas wrote:
Spotted while testing pg_recvlogical:
1. Set up pg_recvlogical to receive:
./pg_recvlogical -S fooslot -d postgres --create
./pg_recvlogical -S fooslot -d postgres --start -f -
2. In another terminal, with psql:
create table foo (id int4);
beg
On 2014-05-13 17:43:47 +0300, Heikki Linnakangas wrote:
> On 05/13/2014 04:35 PM, Andres Freund wrote:
> >On 2014-05-13 16:31:25 +0300, Heikki Linnakangas wrote:
> >>Another thing I noticed is that if when the output goes to a file, the file
> >>isn't re-opened immediately on SIGHUP. Only after rec
Spotted while testing pg_recvlogical:
1. Set up pg_recvlogical to receive:
./pg_recvlogical -S fooslot -d postgres --create
./pg_recvlogical -S fooslot -d postgres --start -f -
2. In another terminal, with psql:
create table foo (id int4);
begin;
insert into foo values (4);
alter table foo a
Hi all,
today I got a few of errors like these (this one is from last week, though):
Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT
Content:
snapshot to old: Wed May 7 04:36:57 2014 GMT
on the new buildfarm animals. I believe it was my mistake (incorrectly
configured l
Alvaro Herrera writes:
> Tom Lane wrote:
>> It might also be reasonable to create a wrapper macro along the line of
>> "PG_STD_IO_BUFFERING()" that would encapsulate the whole sequence
>> setvbuf(stdout, NULL, _IOLBF, 0);
>> setvbuf(stderr, NULL, _IONBF, 0);
>> Or maybe we should have separate mac
On Thu, May 15, 2014 at 11:36:51PM +0900, Amit Langote wrote:
> > No, all memory allocat is per-process, except for shared memory. We
> > probably need a way to record our large local memory allocations in
> > PGPROC that other backends can see; same for effective cache size
> > assumptions we ma
Tom Lane wrote:
> It might also be reasonable to create a wrapper macro along the line of
> "PG_STD_IO_BUFFERING()" that would encapsulate the whole sequence
> setvbuf(stdout, NULL, _IOLBF, 0);
> setvbuf(stderr, NULL, _IONBF, 0);
> Or maybe we should have separate macros for those two
On 04/14/2014 11:55 AM, Marko Kreen wrote:
On Sun, Apr 13, 2014 at 05:46:20PM -0400, Jan Wieck wrote:
On 04/13/14 14:22, Jan Wieck wrote:
On 04/13/14 08:27, Marko Kreen wrote:
I think you need to do SET_VARSIZE also here. Alternative is to
move SET_VARSIZE after sort_snapshot().
And it seems
>From the department of punishing good deeds ... in commit 2dc4f011fd
I added setvbuf() calls to initdb to ensure that output to stdout and
stderr would appear in a consistent order regardless of whether the
output was going to a terminal or a file. The buildfarm shows that
on several (but not all
On 2014-05-15 17:21:28 +0300, Heikki Linnakangas wrote:
> >Is it guaranteed that all paths have called LWLockReleaseAll()
> >before calling the proc exit hooks? Otherwise we might end up waiting
> >for ourselves...
>
> Hmm. AbortTransaction() will release locks before we get here, but the
> before
On Thu, May 15, 2014 at 11:24 PM, Bruce Momjian wrote:
> On Thu, May 15, 2014 at 10:23:19PM +0900, Amit Langote wrote:
>> On Thu, May 15, 2014 at 9:06 PM, Bruce Momjian wrote:
>> >
>> > This is the same problem we had with auto-tuning work_mem, in that we
>> > didn't know what other concurrent ac
On Thu, May 15, 2014 at 10:23:19PM +0900, Amit Langote wrote:
> On Thu, May 15, 2014 at 9:06 PM, Bruce Momjian wrote:
> >
> > This is the same problem we had with auto-tuning work_mem, in that we
> > didn't know what other concurrent activity was happening. Seems we need
> > concurrent activity d
On 05/06/2014 02:44 PM, Andres Freund wrote:
On 2014-05-05 13:41:00 +0300, Heikki Linnakangas wrote:
+/*
+ * Exit hook to unlock the global transaction entry we're working on.
+ */
+static void
+AtProcExit_Twophase(int code, Datum arg)
+{
+ /* same logic as abort */
+ AtAbort_Twophas
On 05/15/2014 04:15 PM, Michael Paquier wrote:
On Thu, May 15, 2014 at 6:20 PM, Heikki Linnakangas
wrote:
Ok, I committed #undefs. I don't have a Mingw(-w64) environment to test
with, so let's see if the buildfarm likes it.
There does not seem to be a buildfarm machine using MinGW-w64...
Jac
On Thu, May 15, 2014 at 9:06 PM, Bruce Momjian wrote:
>
> This is the same problem we had with auto-tuning work_mem, in that we
> didn't know what other concurrent activity was happening. Seems we need
> concurrent activity detection before auto-tuning work_mem and
> effective_cache_size.
>
Perh
On Thu, May 15, 2014 at 6:20 PM, Heikki Linnakangas
wrote:
> Ok, I committed #undefs. I don't have a Mingw(-w64) environment to test
> with, so let's see if the buildfarm likes it.
There does not seem to be a buildfarm machine using MinGW-w64... Btw,
I tested latest master on a Windows box and Min
On Tue, May 6, 2014 at 11:15:17PM +0100, Simon Riggs wrote:
> > Well, for what it's worth, I've encountered systems where setting
> > effective_cache_size too low resulted in bad query plans, but I've
> > never encountered the reverse situation.
>
> I agree with that.
>
> Though that misses my p
On 05/14/2014 08:49 PM, Euler Taveira wrote:
While updating pt-br translation I noticed that some sentences could be
improved. I also fix some style glitches. A set of patches are attached.
Thanks, applied.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Hi,
On 2014-05-13 18:58:11 -0400, Tom Lane wrote:
> Anyway it looks like clock_gettime() might be worth using on Linux
> just for the more precise output. It doesn't seem to exist on OS X
> though, and I have no idea about elsewhere.
Agreed that using clock_gettime() would be a good idea. I'd sa
On 2014-05-15 12:04:25 +0100, Benedikt Grundmann wrote:
> On Thu, May 15, 2014 at 11:31 AM, Greg Stark wrote:
>
> > On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann
> > wrote:
> > > I posted this on this mailing list before at Jane Street we have
> > developed
> > > very fast code to get timi
On Thu, May 15, 2014 at 11:31 AM, Greg Stark wrote:
> On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann
> wrote:
> > I posted this on this mailing list before at Jane Street we have
> developed
> > very fast code to get timing information based on TSC if available. It's
> > all ocaml but well
On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann
wrote:
> I posted this on this mailing list before at Jane Street we have developed
> very fast code to get timing information based on TSC if available. It's
> all ocaml but well documented and mostly just calls to c functions so should
> be ea
On 05/14/2014 06:06 PM, Noah Misch wrote:
On Wed, May 14, 2014 at 05:51:24PM +0300, Heikki Linnakangas wrote:
On 05/14/2014 05:37 PM, Noah Misch wrote:
On Wed, May 14, 2014 at 03:15:38PM +0300, Heikki Linnakangas wrote:
On 05/09/2014 02:56 AM, Noah Misch wrote:
MinGW:
http://sourceforge.net/
Hi All,
I am runnig dbt2 with last postgresql kit. pg9.4. I tried everything again
after setting up awhole new machine again with ubuntu. Still facing the
same error.
I run the the *dbt2-pgsql-build-db -w 1 *
but, after some time, I faced this error
*/home/abhi/dbt2_install/bin/dbt2-pgsql-load
New version of the selectivity estimation patch attached. I am adding
it to CommitFest 2014-06. Previous version of it reviewed by
Andreas Karlson on the previous CommitFest with the GiST support patch.
The new version includes join selectivity estimation.
Join selectivity is calculated in 4 steps
On Thu, May 15, 2014 at 8:19 AM, Benedikt Grundmann <
bgrundm...@janestreet.com> wrote:
> I posted this on this mailing list before at Jane Street we have developed
> very fast code to get timing information based on TSC if available. It's
> all ocaml but well documented and mostly just calls to
I posted this on this mailing list before at Jane Street we have developed
very fast code to get timing information based on TSC if available. It's
all ocaml but well documented and mostly just calls to c functions so
should be easy to port to C and we release it under a very liberal license
so it
85 matches
Mail list logo
