On Wed, May 18, 2016 at 6:25 AM, Andres Freund wrote:
> currently we IIRC use linearly sorted datums for the search in
> individual btree nodes. Not surprisingly that's often one of the
> dominant entries in profiles. We could probably improve upon that by
> using an order more optimized for effi
On Wed, May 18, 2016 at 6:55 AM, Simon Riggs wrote:
> I think its a good area of work.
I strongly agree.
Abbreviated keys in indexes are supposed to help with this. Basically,
the ItemId array is made to be interlaced with small abbreviated keys
(say one or two bytes), only in the typically less
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
Well, there's FE/BE level batching/pipelining already. Just no access to it
from libpq.
Oh, really. The Bind ('B') appears to take one set of parameter values, not
multiple sets (arra
I recently had to run something like:
alter table pgbench_accounts add locked text check (locked != 'unlocked');
And was surprised that it took several minutes to complete as it
scanned the whole table.
The new column is going to start out as NULL in every row, so there is
no need to validate th
> On May 19, 2016, at 5:24 PM, Евгений Шишкин wrote:
>
>
>> On 20 May 2016, at 01:12, Tom Lane wrote:
>>
>>
>> I'm a bit inclined to think that what this is really about is that we
>> made the wrong call on the BUFFERS option, and that it should default
>> to ON just like COSTS and TIMING do
> On 20 May 2016, at 01:12, Tom Lane wrote:
>
>
> I'm a bit inclined to think that what this is really about is that we
> made the wrong call on the BUFFERS option, and that it should default
> to ON just like COSTS and TIMING do. Yeah, that would be an incompatible
> change, but that's what m
On Thu, May 19, 2016 at 4:14 PM, Michael Paquier
wrote:
> Comments are welcome, I am adding that in the 9.7 queue.
Take that as 10.0 as things are going.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On 20/05/16 10:11, David G. Johnston wrote:
[...]
EXPAIN ABCTV (might need permission to document this variation though)
What has an Australian Broadcast Corporation Television got to do with
this??? :-)
[...]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KjQuNGI0LrQuNC9?= writes:
>> On 19 May 2016, at 22:59, Tom Lane wrote:
>> I'm not sure this is well thought out. It would mean for example that
>> we could never implement EXPLAIN options that are mutually exclusive
>> ... at least, not without having to redefine A
On Thursday, May 19, 2016, David Christensen wrote:
>
> > On May 19, 2016, at 3:17 PM, Евгений Шишкин > wrote:
> >
> >
> >> On 19 May 2016, at 22:59, Tom Lane >
> wrote:
> >>
> >> David Christensen > writes:
> >>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for
> “EXPLAIN (ANA
Hi,
I have gone through all our extensions and tried to tag all functions
correctly according to their parallel safety.
I also did the same for the aggregate functions in a second patch, and
for min(citext)/max(citext) set a COMBINEFUNC.
The changes for the functions is attached as one huge
> On May 19, 2016, at 3:17 PM, Евгений Шишкин wrote:
>
>
>> On 19 May 2016, at 22:59, Tom Lane wrote:
>>
>> David Christensen writes:
>>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for “EXPLAIN
>>> (ANALYZE, VERBOSE, COSTS, TIMING, BUFFERS)” for usability.
>>
>> I'm not
Евгений Шишкин wrote:
> Maybe EVERYTHING would be ok.
> But it is kinda long word to type.
There's never need to run the EXPLAIN (EVERTHING) command; you already
know that the answer is 42.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
> On 19 May 2016, at 22:59, Tom Lane wrote:
>
> David Christensen writes:
>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for “EXPLAIN
>> (ANALYZE, VERBOSE, COSTS, TIMING, BUFFERS)” for usability.
>
> I'm not sure this is well thought out. It would mean for example that
> w
Hi all,
As I mentioned $subject a couple of months back after looking at the
wait event facility here:
http://www.postgresql.org/message-id/CAB7nPqTJpgAvOK4qSC96Fpm5W+aCtJ9D=3Vn9AfiEYsur=-j...@mail.gmail.com
I have actually taken some time to implement this idea.
The particular case that I had in
On Thu, May 19, 2016 at 12:59 PM, Tom Lane wrote:
>
> I'm not sure this is well thought out. It would mean for example that
> we could never implement EXPLAIN options that are mutually exclusive
> ... at least, not without having to redefine ALL as all-except-something.
> Non-boolean options woul
David Christensen writes:
> This simple patch adds âALLâ as an EXPLAIN option as shorthand for
> âEXPLAIN (ANALYZE, VERBOSE, COSTS, TIMING, BUFFERS)â for usability.
I'm not sure this is well thought out. It would mean for example that
we could never implement EXPLAIN options that are mu
This simple patch adds “ALL” as an EXPLAIN option as shorthand for “EXPLAIN
(ANALYZE, VERBOSE, COSTS, TIMING, BUFFERS)” for usability.
0001-Add-EXPLAIN-ALL-shorthand.patch
Description: Binary data
--
David Christensen
End Point Corporation
da...@endpoint.com
785-727-1171
--
Sent via pgsql
Tom Lane wrote:
> Commit 473b93287 forgot a rather critical detail:
>
> regression=# drop access method btree;
> DROP ACCESS METHOD
> regression=# select * from tenk1;
> ERROR: cache lookup failed for access method 403
Hah, nice one. Thanks for fixing.
--
Álvaro Herrerahttp://
Commit 473b93287 forgot a rather critical detail:
regression=# drop access method btree;
DROP ACCESS METHOD
regression=# select * from tenk1;
ERROR: cache lookup failed for access method 403
The fact that the command is restricted to superusers doesn't make
this a good idea.
Hi all,
I just bumped into the following typo for $subject:
--- a/src/bin/initdb/t/001_initdb.pl
+++ b/src/bin/initdb/t/001_initdb.pl
@@ -31,7 +31,7 @@ command_fails(
command_fails(
[ 'initdb', '-U', 'pg_test', $datadir ],
- 'role names cannot being with "pg_"');
+ 'role name
Hi,
Since 34d26872ed816b2 ("Support ORDER BY within aggregate function
calls") we use ExecProject() and a slot within advance_aggregates().
Previous to that patch we simply directly filled fcinfo.args with
ExecEvalExpr().
According to my profiles the new way generally is considerably slower,
but
Robert,
(and others who are involved in parallel query of PostgreSQL)
PostgreSQL Enterprise Consortium (one of the PostgreSQL communities in
Japan, in short "PGECons") is planning to test the parallel query
performance of PostgreSQL 9.6. Besides TPC-H (I know you have already
tested on an IBM box)
On Mon, Mar 28, 2016 at 2:05 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> After some debugging I found that vac_truncate_clog consumes xid just to
> produce warning. I wrote simple patch which replaces
> GetCurrentTransactionId() with ShmemVariableCache->nextXid. That
> completel
On 19 May 2016 at 14:08, Tsunakawa, Takayuki wrote:
>
>
> Yes, I want FE-BE protocol-level batch inserts/updates/deletes, too. I
> was just about to start thinking of how to implement it because of recent
> user question in pgsql-odbc. The OP uses Microsoft SQL Server Integration
> Service (SS
On 2016/05/19 2:48, Tom Lane wrote:
> Amit Langote writes:
>> On 2016/05/18 2:22, Tom Lane wrote:
>>> The two ways that we've dealt with this type of hazard are to copy data
>>> out of the relcache before using it; or to give the relcache the
>>> responsibility of not moving a particular portion o
Hi,
I want to discuss about inherits in PostgreSQL.
Everything I write here is my own opinion, but I hope for a good dialog.
I think that inherits is a feature to good to be plain legacy, but it is
unfortunately riddled with some inconsistencies. The inheritance keyword
link tables together in a
Currently in HEAD and 9.6, one can issue a non-exclusive backup on
standby, so this is OK:
select pg_is_in_recovery();
pg_is_in_recovery
---
t
(1 row)
select pg_start_backup('sby-bkp-test', 'f', 'f');
pg_start_backup
-
0/5000220
(1 row)
However the following h
28 matches
Mail list logo
