On Thu, Jun 5, 2014 at 5:37 PM, Peter Geoghegan wrote:
> One thing that isn't all that obvious about this worst case is that
> it's in general very qsort() friendly, and therefore the startup costs
> (copying) totally dominates. Actually, you're not even sorting -
> you're verifying that the tuple
On 06/06/2014 03:23 PM, David E. Wheeler wrote:
> On Jun 6, 2014, at 12:51 PM, Josh Berkus wrote:
>> Well, I'd also say that we don't care about syntaxes which are not
>> already popular. There's no point in being compatible with something
>> nobody uses. How many of the above have any uptake?
>
On Jun 6, 2014, at 12:51 PM, Josh Berkus wrote:
>> * [JAQL](https://code.google.com/p/jaql/): Too different from SQL
>> * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose
>
> I don't agree with the too verbose, but lacking AND|OR is pretty crippling.
I had enough people complain
On 6/5/14, 9:54 PM, Tom Lane wrote:
Rod Taylor writes:
On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane wrote:
I'm not entirely convinced that it's worth the extra planning cycles,
though. Given the small number of complaints to date, it might not
be worth doing this. Thoughts?
Would this avoid
On 2014-06-06 15:44:25 -0400, Tom Lane wrote:
> I figured it'd be easy enough to get a better estimate by adding another
> counter to count just LIVE and INSERT_IN_PROGRESS tuples (thus effectively
> assuming that in-progress inserts and deletes will both commit). I did
> that, and found that it h
On 06/06/2014 09:12 AM, David E. Wheeler wrote:
> On Jun 6, 2014, at 6:54 AM, Oleg Bartunov wrote:
>
>> Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.
>
> Sure, but could we not potentially build on its syntax, instead of building a
> new one? I’m not saying we *sho
I've been looking at the complaint Tim Wilson posted in pgsql-performance
about badly inaccurate reltuples updates coming from VACUUM. There seem
to be a number of problems leading to that. The key point is that when
VACUUM has scanned only part of the relation, it assumes that the
live-tuple den
On 6/4/14, 8:56 AM, Andres Freund wrote:
On 2014-06-04 09:51:36 -0400, Robert Haas wrote:
>On Wed, Jun 4, 2014 at 2:08 AM, Andres Freund wrote:
> >On 2014-06-04 10:24:13 +0530, Amit Kapila wrote:
> >>Incase of recovery, the shared buffers saved by this utility are
> >>from previous shutdown w
Bruce Momjian wrote:
> On Wed, May 28, 2014 at 12:29:28PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I think this is caused because the variable is not defined as SOCKET.
> > > The attached patch fixes this. This should prevent the warning.
> >
> > Surely that's just going to move t
On Fri, Jun 6, 2014 at 8:05 PM, wrote:
>> -Original Message-
>> > > Flush is not performed every time write, it is performed
>> > > collectively like walrecever.
>> >
>> > I only glanced at this, but afaics you're only flushing at the end
>> > every WAL segment. That will result in absolu
On Jun 6, 2014, at 6:54 AM, Oleg Bartunov wrote:
> Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.
Sure, but could we not potentially build on its syntax, instead of building a
new one? I’m not saying we *should*, but if we don’t, I think there should be a
discussio
Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.
On Fri, Jun 6, 2014 at 4:34 AM, David E. Wheeler wrote:
> On Jun 5, 2014, at 5:25 PM, Andrew Dunstan wrote:
>
>> My understanding is that it's meant to be analogous to tsquery.
>>
>> At first glance, JsonPath doesn't seem
On Thu, Jun 5, 2014 at 11:32 PM, Amit Kapila wrote:
> On Thu, Jun 5, 2014 at 5:39 PM, Gurjeet Singh wrote:
>>
>> > On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh wrote:
>> Case 2 also won't cause any buffer restores because the save-files are
>> created only on clean shutdowons; not on a crash or
Hello
where we are with this feature?
Is there some barriers to commit bugfix?
Regards
Pavel
2014-05-18 19:46 GMT+02:00 Sergey Muraviov :
> I found some new bugs and fix them.
> And I had to make many changes.
>
>
> 2014-05-17 21:31 GMT+04:00 Greg Stark :
>
> Sorry, a couple things still loo
> -Original Message-
> > > Flush is not performed every time write, it is performed
> > > collectively like walrecever.
> >
> > I only glanced at this, but afaics you're only flushing at the end
> > every WAL segment. That will result in absolutely horrible performance,
> right?
> > Walrece
On Thu, Jun 5, 2014 at 11:32 PM, Amit Kapila wrote:
> Another thing is don't you want to handle SIGQUIT signal in bg saver?
I think bgworker_quickdie registered in StartBackgroundWorker() serves
the purpose just fine.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
EDB www.EnterpriseD
Hi All,
When log_duration is true ( or log_min_duration_statement>=0 ),
If a transaction has internally been commited receives a SIGINT signal
then a query cancellation error is output.
For example,
1. A query like a TRUNCATE is removing bigger table files.
2. The session receives SIGINT signal.
On Fri, Jun 6, 2014 at 11:44 AM, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
> >> A bit more crazy, but how about trying trying to plan joins with a added
> >> one-time qual that checks the size of the deferred trigger queue? Then
> >>
18 matches
Mail list logo
