On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas wrote:
> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule wrote:
>> Yes, what I know almost all use utf8 without problems. Long time I didn't
>> see any request for multi encoding support.
>
> Well, not *everything* can be represented as UTF-8; I think th
>
> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
wrote:
> > Yes, what I know almost all use utf8 without problems. Long time I
> > didn't see any request for multi encoding support.
>
> Well, not *everything* can be represented as UTF-8; I think this is
> particularly an issue with Asian langua
On Sun, Jul 14, 2013 at 8:27 PM, Robert Haas wrote:
> On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus wrote:
> >> I think it's a waste of code to try to handle bushy trees. A list is
> >> not a particularly efficient representation of the pending list; this
> >> will probably be slower than recusi
On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner wrote:
> One way to resolve that - and that seems to be the direction Dimitri's
> patch is going - is to make the extension depend on its template. (And
> thereby breaking the mental model of a template, IMO. In the spirit of
> that mental model, one c
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule wrote:
> Yes, what I know almost all use utf8 without problems. Long time I didn't
> see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue with Asian languages.
If we cho
On Sun, Jul 14, 2013 at 10:15:12PM -0400, Noah Misch wrote:
> On Sun, Jul 07, 2013 at 06:37:26PM -0700, David Fetter wrote:
> > On Sat, Jul 06, 2013 at 11:49:21AM +0100, Dean Rasheed wrote:
> > > Overall I think this patch offers useful additional functionality, in
> > > compliance with the SQL spe
On Sat, Jul 6, 2013 at 9:27 AM, Andrew Dunstan wrote:
> Or maybe just invent a magic result file name such as "none" or
> "do_not_run".
>
> I'm not keen to have us build up a large patchwork of regression tests that
> run on some platforms and not on others, though.
Me, neither. But I don't real
On Fri, Jul 5, 2013 at 4:18 PM, Jeff Davis wrote:
> On Tue, 2013-07-02 at 10:12 -0700, Jeff Davis wrote:
>> Regardless, this is at least a concrete issue that I can focus on, and I
>> appreciate that. Are scans of small tables the primary objection to this
>> patch, or are there others? If I solve
On Sun, Jul 07, 2013 at 06:37:26PM -0700, David Fetter wrote:
> On Sat, Jul 06, 2013 at 11:49:21AM +0100, Dean Rasheed wrote:
> > Overall I think this patch offers useful additional functionality, in
> > compliance with the SQL spec, which should be handy to simplify
> > complex grouping queries.
On Wed, Jul 10, 2013 at 9:02 PM, Josh Berkus wrote:
>> I think it's a waste of code to try to handle bushy trees. A list is
>> not a particularly efficient representation of the pending list; this
>> will probably be slower than recusing in the common case. I'd suggest
>> keeping the logic to ha
On Sun, Jul 14, 2013 at 8:41 PM, Tom Lane wrote:
> Commit 9a20a9b2 breaks the build for me, using gcc on HPPA:
>
> xlog.c:2182: macro `pg_memory_barrier' used without args
> xlog.c:2546: macro `pg_memory_barrier' used without args
> make[4]: *** [xlog.o] Error 1
>
> The reason for this is that the
On Sunday, July 14, 2013, Greg Smith wrote:
> On 6/27/13 11:08 AM, Robert Haas wrote:
>
>> I'm pretty sure Greg Smith tried it the fixed-sleep thing before and
>> it didn't work that well.
>>
>
> That's correct, I spent about a year whipping that particular horse and
> submitted improvements on it
On Sunday, July 14, 2013, Greg Smith wrote:
> On 7/14/13 5:28 PM, james wrote:
>
>> Some random seeks during sync can't be helped, but if they are done when
>> we aren't waiting for sync completion then they are in effect free.
>>
>
> That happens sometimes, but if you measure you'll find this doe
Commit 9a20a9b2 breaks the build for me, using gcc on HPPA:
xlog.c:2182: macro `pg_memory_barrier' used without args
xlog.c:2546: macro `pg_memory_barrier' used without args
make[4]: *** [xlog.o] Error 1
The reason for this is that the "fallback" definition of
pg_memory_barrier has been wrong sin
On 7/10/13 9:39 AM, Heikki Linnakangas wrote:
On 10.07.2013 02:54, Josh Berkus wrote:
One bit of complexity I'd like to see go away is that we have two
trigger files: one to put a server into replication, and one to promote
it. The promotion trigger file is a legacy of warm standby, I believe.
Michael,
While looking at complaints from the Coverity scanner system, it looks
like it's detected a case in ECPG where we provide a "day-of-year"
format option (%j), but we never actually calculate what the day of
year *is*, resulting in an uninitialized value.
Other parts of the code
On 7/14/13 5:28 PM, james wrote:
Some random seeks during sync can't be helped, but if they are done when
we aren't waiting for sync completion then they are in effect free.
That happens sometimes, but if you measure you'll find this doesn't
actually occur usefully in the situation everyone di
On 7/11/13 8:29 AM, KONDO Mitsumasa wrote:
> I use linear combination method for considering about total checkpoint
> schedule
> which are write phase and fsync phase. V3 patch was considered about only
> fsync
> phase, V4 patch was considered about write phase and fsync phase, and v5 patch
> was
Hello Greg,
Correct patch (and the little one from me again) attached this time.
Please find an updated v15 with only comment changes:
* The new comment about "is_throttled" was inverted wrt the meaning of the
variable, at least to my understanding.
* ISTM that the impact of the chosen 10
On 14/07/2013 20:13, Greg Smith wrote:
The most efficient way to write things out is to delay those writes as
long as possible.
That doesn't smell right to me. It might be that delaying allows more
combining and allows the kernel to see more at once and optimise it, but
I think the counter-a
While doing some post-commit review of the 9.3 materialized view feature, I
noticed a few loose ends:
On Thu, Jan 24, 2013 at 01:09:28PM -0500, Noah Misch wrote:
> Note that [...] "ALTER TABLE ... RENAME CONSTRAINT" [is]
> currently supported for MVs by ALTER TABLE but not by ALTER MATERIALIZED VI
On 7/3/13 9:39 AM, Andres Freund wrote:
I wonder how much of this could be gained by doing a
sync_file_range(SYNC_FILE_RANGE_WRITE) (or similar) either while doing
the original checkpoint-pass through the buffers or when fsyncing the
files.
The fsync calls decomposing into the queued set of blo
On 7/14/13 2:48 PM, Fabien COELHO wrote:
You attached my v13. Could you send your v14?
Correct patch (and the little one from me again) attached this time.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On 6/27/13 11:08 AM, Robert Haas wrote:
I'm pretty sure Greg Smith tried it the fixed-sleep thing before and
it didn't work that well.
That's correct, I spent about a year whipping that particular horse and
submitted improvements on it to the community.
http://www.postgresql.org/message-id/4d
Hello Greg,
But we don't have to argue about that because it isn't. The attached new
patch seems to fix the latency spikes at the end, with -2 lines of new code!
Hmmm... that looks like not too much complexity:-)
With that resolved I did a final pass across the rate limit code too,
attache
On 6/16/13 10:27 AM, Heikki Linnakangas wrote:
Yeah, the checkpoint scheduling logic doesn't take into account the
heavy WAL activity caused by full page images...
Rationalizing a bit, I could even argue to myself that it's a *good*
thing. At the beginning of a checkpoint, the OS write cache shou
On 7/13/13 12:13 PM, Fabien COELHO wrote:
My 0.02€: if it means adding complexity to the pgbench code, I think
that it is not worth it. The point of pgbench is to look at a steady
state, not to end in the most graceful possible way as far as measures
are concerned.
That's how some people use pg
Heikki,
* Heikki Linnakangas (heikki.linnakan...@iki.fi) wrote:
> This patch alleviates that in two ways. First, instead of storing pointers
> in the hash table, store 16-bit indexes into the hist_entries array. That
> slashes the size of the hash table to 1/2 or 1/4 of the original, depending
> o
Sent from my iPad
On 14-Jul-2013, at 22:12, Hannu Krosing wrote:
> On 07/14/2013 06:10 PM, Atri Sharma wrote:
>>
>> Sent from my iPad
>>
>> On 10-Jul-2013, at 13:11, Hannu Krosing wrote:
>>
>>> On 07/10/2013 09:18 AM, Atri Sharma wrote:
> Can you please post an example of such a join r
On 07/14/2013 06:10 PM, Atri Sharma wrote:
>
> Sent from my iPad
>
> On 10-Jul-2013, at 13:11, Hannu Krosing wrote:
>
>> On 07/10/2013 09:18 AM, Atri Sharma wrote:
Can you please post an example of such a join removal? I mean a query
before
and after the removal. Thanks,
>>> Courte
Sent from my iPad
On 10-Jul-2013, at 13:11, Hannu Krosing wrote:
> On 07/10/2013 09:18 AM, Atri Sharma wrote:
>>> Can you please post an example of such a join removal? I mean a query before
>>> and after the removal. Thanks,
>> Courtesy Robert Haas:
>>
>> SELECT foo.x, foo.y, foo.z FROM foo
On Sun, Jul 14, 2013 at 03:36:09AM -0300, Fabrízio de Royes Mello wrote:
> > Next, changes in src/backend, starting with parser changes: the patch
> > adds "IF_P NOT EXISTS" variants for various productions. For example:
> > I think opt_if_not_exists should be used for the others as well.
> >
>
32 matches
Mail list logo
