> 17 мая 2019 г., в 18:40, Gasper Zejn написал(а):
>
> I've tested according to instructions at the test repo
> https://github.com/x4m/test_pglz
>
> Test_pglz is at a97f63b and postgres at 6ba500.
>
> Hardware is desktop AMD Ryzen 5 2600, 32GB RAM
>
> Decompressor score (summ of all times):
Hi,
On 2019-05-17 14:49:19 -0700, Ashwin Agrawal wrote:
> On Fri, May 17, 2019 at 12:54 PM Andres Freund wrote:
>
> > Hi,
> >
> > On 2019-05-15 23:00:38 -0700, Ashwin Agrawal wrote:
> > > Highlevel this looks good to me. Will look into full details tomorrow.
> >
> > Ping?
> >
> > I'll push the f
On Fri, May 17, 2019 at 6:36 PM Tom Lane wrote:
> Will do so tomorrow. Should we back-patch this?
I wouldn't, because I see no reason to. Somebody else might.
--
Peter Geoghegan
Peter Geoghegan writes:
> On Tue, Apr 30, 2019 at 3:22 PM Tom Lane wrote:
>> So now I'm feeling more favorable about the idea of adding a
>> PrepareTempTablespaces call to BufFileCreateTemp, and just stopping
>> with that. If we want to do more, I feel like it requires a
>> significant amount of
Hi,
On 2019-04-17 19:22:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-04-17 18:57:00 -0400, Tom Lane wrote:
> >> What on God's green earth are these functions doing in
> >> src/include/catalog/index.h?
>
> > I'm happy to move them elsewhere, but I'm not sure there's really a good
On Sat, May 18, 2019 at 6:44 AM David Rowley
wrote:
> On Sat, 18 May 2019 at 12:49, Andres Freund wrote:
> >
> > On 2019-05-18 06:14:15 +0530, Ashutosh Sharma wrote:
> > > I actually feel that the function name itself is not correct here, it
> > > appears to be confusing and inconsistent conside
David Rowley writes:
> On Sat, 18 May 2019 at 12:49, Andres Freund wrote:
>> Unless somebody else presses back hard against doing so *soon*, I'm
>> going to close this open issue. I don't think it's worth spending
>> further time arguing about a few characters.
> I'd say if we're not going to bo
Melanie Plageman writes:
> So, I noticed that if I make a table in one schema and then a table with the
> same name in another schema that describe only shows me one of them.
Yes, that's intended, psql's \d will only show you tables that are
visible in the search path, unless you give it a qualif
Andres Freund writes:
> Robert, this indeed looks near trivial. What do you think?
> On 2019-05-09 14:14:20 +0900, Masahiko Sawada wrote:
>> +"toast.vacuum_index_clenaup",
Not trivial enough to not have typos, apparently.
regards, tom lane
On Sat, 18 May 2019 at 12:49, Andres Freund wrote:
>
> On 2019-05-18 06:14:15 +0530, Ashutosh Sharma wrote:
> > I actually feel that the function name itself is not correct here, it
> > appears to be confusing and inconsistent considering the kind of work that
> > it is doing. I think, the functio
Mark Dilger writes:
> most places that use SPI_connect ... SPI_finish check the
> return value of SPI_finish and elog if it failed. There
> are a few places that do not, and it is unclear to me
> why this is safe. SPI_finish appears to be needed to
> clean up memory contexts.
Well, looking thro
So, I noticed that if I make a table in one schema and then a table with the
same name in another schema that describe only shows me one of them.
Demonstrating with temp table and regular table just for simplicity:
If I make a temp table t1 and a normal table t1 (it doesn't
matter which one I creat
On Tue, Apr 30, 2019 at 3:22 PM Tom Lane wrote:
> So now I'm feeling more favorable about the idea of adding a
> PrepareTempTablespaces call to BufFileCreateTemp, and just stopping
> with that. If we want to do more, I feel like it requires a
> significant amount of rethinking about what the expe
Hi,
On 2019-05-18 06:14:15 +0530, Ashutosh Sharma wrote:
> On Sat, May 18, 2019 at 1:34 AM Andres Freund wrote:
> Considering that we can have MAX_BUFFERED_TUPLES slots in each multi-insert
> buffer and we do flush the buffer after MAX_BUFFERED_TUPLES tuples have
> been stored, it seems unlikely
On Sat, May 18, 2019 at 1:34 AM Andres Freund wrote:
> On 2019-05-17 11:09:41 +0530, Ashutosh Sharma wrote:
> > On Fri, May 17, 2019 at 3:10 AM Alvaro Herrera >
> > wrote:
> >
> > > On 2019-May-14, Michael Paquier wrote:
> > >
> > > > On Tue, May 14, 2019 at 01:19:30PM +1200, David Rowley wrote:
On Thu, May 16, 2019 at 3:22 PM Thomas Munro wrote:
> Admittedly I don't have a patch, just a bunch of handwaving. One
> reason I haven't attempted to write it is because although I know how
> to do the non-parallel version using a BufFile full of match bits in
> sync with the tuples for outer j
Hi,
On 2019-05-17 16:56:04 -0700, Ashwin Agrawal wrote:
> Question on the patch, if not too late
> Why call table_beginscan() in TidNext() and not in ExecInitTidScan() ?
> Seems cleaner to have it in ExecInitTidScan().
Largely because it's symmetrical to where most other scans are started (
c.f.
On Wed, May 15, 2019 at 11:54 AM Andres Freund wrote:
> Attached is a prototype of a variation of this. I added a
> table_tuple_tid_valid(TableScanDesc sscan, ItemPointer tid)
> callback / wrapper. Currently it just takes a "plain" scan, but we could
> add a separate table_beginscan variant too.
On Tue, Apr 9, 2019 at 6:17 AM Heikki Linnakangas wrote:
> On 08/04/2019 20:37, Andres Freund wrote:
> > On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> >> There's a little bug in index-only scan executor node, where it mixes
> up the
> >> slots to hold a tuple from the index, and from
On Fri, May 17, 2019 at 2:42 PM Robert Haas wrote:
> In any case, it bears saying that
> tableam is a remarkable accomplishment regardless of whatever
> shortcomings it has in this area or elsewhere.
>
Big +1 to this.
Mark Dilger writes:
> On May 17, 2019, at 12:10 PM, Tom Lane wrote:
>> Anybody around here got large patches they're carrying against
>> back branches, that they could try reapplying after running
>> a newer version of pgindent?
> I have forks of 9.1 and 9.5 that each amount to large changes
> a
On Fri, May 17, 2019 at 12:54 PM Andres Freund wrote:
> Hi,
>
> On 2019-05-15 23:00:38 -0700, Ashwin Agrawal wrote:
> > Highlevel this looks good to me. Will look into full details tomorrow.
>
> Ping?
>
> I'll push the first of the patches soon, and unless you'll comment on
> the second soon, I'l
On Fri, May 17, 2019 at 3:28 PM Andres Freund wrote:
> > - If your AM uses some system other than TOAST to store large values,
> > you are out of luck. You will get TOAST tables whether you want them
> > or not.
>
> Which is aesthetically and indode usage wise annoying, but not
> *terrible*. You
> On May 17, 2019, at 12:10 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> On 2019-05-17 13:47:02 -0400, Tom Lane wrote:
>>> I dunno, how far back are you thinking? I've occasionally wished we
>>> could reindent all the back branches to match HEAD, but realistically,
>>> people carrying ou
On Fri, May 17, 2019 at 11:34 AM Andres Freund wrote:
> Hi,
>
> On 2019-05-17 11:26:29 -0700, Ashwin Agrawal wrote:
> > Currently TOAST table is always created (if needed based on data type
> > properties) independent of table AM. How toasting is handled seems
> > should be AM responsibility. Gen
On Fri, May 17, 2019 at 1:51 PM Andres Freund wrote:
>
> > /*
>
> > * Planner related callbacks for the heap AM
> > @@ -2558,6 +2615,8 @@ static const TableAmRoutine heapam_methods = {
> >
> > .relation_estimate_siz
Hi,
On 2019-05-09 14:14:20 +0900, Masahiko Sawada wrote:
> I agree that this item is neither critical and bug. But this is an
> (my) oversight and is a small patch and I think there is no specific
> reason why we don't dare to include this in 12. So if this patch could
> get reviewed enough I thin
Hi,
> +
> +/*
> + * Check to see whether the table needs a TOAST table. It does only if
> + * (1) there are any toastable attributes, and (2) the maximum length
> + * of a tuple could exceed TOAST_TUPLE_THRESHOLD. (We don't want to
> + * create a toast table for something like "f1 varchar(20)".)
On Fri, May 17, 2019 at 3:26 PM Tom Lane wrote:
> It seems to me that the entire tableam project is still very much WIP,
> and if anybody is able to do anything actually useful with a different
> AM right at the moment, that's just mighty good fortune for them.
> It's way too late to be making des
Andres Freund writes:
> On 2019-05-01 13:09:07 -0400, Robert Haas wrote:
>> In the email at issue, Tom complains about two things. First, he
>> complains about the fact that I try to arrange things so that relcache
>> data remains valid for as long as required instead of just copying it.
>> Secon
Hi,
On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> 5). Some columns from pg_statistic_ext have to be made visible for
> psql \d to work. Basically, it needs to be able to query for the
> existence of extended statistics, but it doesn't need to see the
> actual statistical data. Of course, we
Hi,
On 2019-05-15 15:44:22 +0900, Masahiko Sawada wrote:
> From de60d212b50a6412e483c995b83e28c5597089ad Mon Sep 17 00:00:00 2001
> From: Masahiko Sawada
> Date: Thu, 9 May 2019 20:02:05 +0900
> Subject: [PATCH v3 1/2] Add --index-cleanup option to vacuumdb.
> From 59e3146f585e288d41738daa9a1d18
On 2019-05-17 11:09:41 +0530, Ashutosh Sharma wrote:
> On Fri, May 17, 2019 at 3:10 AM Alvaro Herrera
> wrote:
>
> > On 2019-May-14, Michael Paquier wrote:
> >
> > > On Tue, May 14, 2019 at 01:19:30PM +1200, David Rowley wrote:
> > > > When I wrote the code I admit that I was probably wearing my
Hi,
On 2019-05-01 13:09:07 -0400, Robert Haas wrote:
> The original issue on this thread was that hyrax started running out
> of memory when it hadn't been doing so previously. That happened
> because, for complicated reasons, commit
> 898e5e3290a72d288923260143930fb32036c00c resulted in the leak
Hi,
On 2019-05-15 23:00:38 -0700, Ashwin Agrawal wrote:
> Highlevel this looks good to me. Will look into full details tomorrow.
Ping?
I'll push the first of the patches soon, and unless you'll comment on
the second soon, I'll also push ahead. There's a beta upcoming...
- Andres
On 2019-05-17 15:26:38 -0400, Tom Lane wrote:
> Robert Haas writes:
> > So I think this basically just doesn't work right now. I am
> > sympathetic to Andres's position that we shouldn't go whacking the
> > code around too much at this late date, and he's probably right that
> > we're going to fi
Hi,
On 2019-05-17 15:13:50 -0400, Robert Haas wrote:
> On Fri, May 17, 2019 at 2:34 PM Andres Freund wrote:
> > Yea, Robert is also working on this. In fact, we were literally chatting
> > about it a few minutes ago. He'll probably chime in too.
>
> Yeah, I'm aiming to post a patch set very soon
Robert Haas writes:
> So I think this basically just doesn't work right now. I am
> sympathetic to Andres's position that we shouldn't go whacking the
> code around too much at this late date, and he's probably right that
> we're going to find lots of other problems with tableam as well and
> you
On Fri, May 17, 2019 at 2:34 PM Andres Freund wrote:
> Yea, Robert is also working on this. In fact, we were literally chatting
> about it a few minutes ago. He'll probably chime in too.
Yeah, I'm aiming to post a patch set very soon that does a bunch of
refactoring of the TOAST stuff to make lif
Andres Freund writes:
> On 2019-05-17 13:47:02 -0400, Tom Lane wrote:
>> I dunno, how far back are you thinking? I've occasionally wished we
>> could reindent all the back branches to match HEAD, but realistically,
>> people carrying out-of-tree patches would scream.
> I somehow thought we'd bac
Hi,
On 2019-05-17 11:26:29 -0700, Ashwin Agrawal wrote:
> Currently TOAST table is always created (if needed based on data type
> properties) independent of table AM. How toasting is handled seems
> should be AM responsibility. Generic code shouldn't force the use of
> the separate table for the s
Currently TOAST table is always created (if needed based on data type
properties) independent of table AM. How toasting is handled seems
should be AM responsibility. Generic code shouldn't force the use of
the separate table for the same. Like for Zedstore we store toasted
chunks in separate blocks
Hi,
On 2019-05-17 13:47:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Would we want to also apply this to the back branches to avoid spurious
> > conflicts?
>
> I dunno, how far back are you thinking? I've occasionally wished we
> could reindent all the back branches to match HEAD, but
Hackers,
most places that use SPI_connect ... SPI_finish check the
return value of SPI_finish and elog if it failed. There
are a few places that do not, and it is unclear to me
why this is safe. SPI_finish appears to be needed to
clean up memory contexts.
Examples can be found in:
src/backend
On Fri, May 17, 2019 at 01:47:02PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
> >> Also, how do people feel about adopting the function prototype
> >> indenting change discussed in
> >> https://www.postgresql.org/message-id/flat/CAEepm%3D0P3FeT
Andres Freund writes:
> On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
>> Also, how do people feel about adopting the function prototype
>> indenting change discussed in
>> https://www.postgresql.org/message-id/flat/CAEepm%3D0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug%40mail.gmail.com
> I think i
On 2019-May-17, Melanie Plageman wrote:
> I realized that the numbers at the front probably indicate which patch
> it is in a patch set and not the version, so, if that is the case, a
> renamed patch -- second version but the only patch needed if you are
> applying to master. Is this right?
That
Hi,
On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
> We should do a pgindent run fairly soon, so that people with patches
> awaiting the next CF will have plenty of time to rebase them as
> necessary.
+1
> I don't want to do it right this minute, to avoid making trouble for the
> several urgent p
On Fri, May 17, 2019 at 10:29:46AM -0400, Tom Lane wrote:
> We should do a pgindent run fairly soon, so that people with patches
> awaiting the next CF will have plenty of time to rebase them as necessary.
> I don't want to do it right this minute, to avoid making trouble for the
> several urgent p
Robert Haas writes:
> I think it's pretty clear that the theoretical beauty of being able to
> handle postfix operators is not worth the tangible cost they impose on
> our parser. We're losing more users as a result of SQL that other
> systems can accept and we cannot than we are gaining by being
On Thu, May 16, 2019 at 8:46 PM Melanie Plageman
wrote:
>
> I squashed the changes I suggested in previous emails, Ashwin's patch, my
> suggested updates to that patch, and the index order check all into one
> updated
> patch attached.
>
>
I realized that the numbers at the front probably indicat
Please help me get out of Nanwarran unit Shep /tomorrow = Saturday 18th of
2019
Guise = voting tell me where you want it to swing??
Please wave your SS wands and help your Ae girl out please; a million
thanks and blessed be/ a thousand virgins or turkeys whatever your fancy
might be,,,
Please ju
On Mon, May 13, 2019 at 2:39 PM Andrew Gierth
wrote:
> Or we could kill off postfix operators...
/me helps Andrew hijack the thread.
We wouldn't even have to go that far. We could just restrict it to a
specific list of operators that are hard-coded into the lexer and
parser, like say only '!'.
Hi,
On 2019-05-17 11:34:25 -0400, Robert Haas wrote:
> table_update and table_delete both have comments that document all of
> their input parameters *except* for snapshot. This seems like an
> oversight
Hm, yea, it ought to be documented.
> , especially because:
>
> * crosscheck - if n
On Fri, May 17, 2019 at 6:50 AM Alexander Korotkov
wrote:
> Couple patches improving jsonpath docs are attached. The first one
> documents nesting level filter for .** accessor. The second adds to
> documentation of jsonpath array subsciption usage of expressions and
> multiple slice ranges. I'
Hi,
table_update and table_delete both have comments that document all of
their input parameters *except* for snapshot. This seems like an
oversight, especially because:
* crosscheck - if not InvalidSnapshot, also check tuple against this
Without a comment about snapshot, what's the "also
I wrote:
>>> A small problem with the "rejiggering" is that it now makes the wrong
>>> choice for K&R-style function definitions, causing them to be weirdly
>>> indented. For our purposes, that's a non-problem so I'm not excited
>>> about trying to make it smart enough to recognize those. We do h
We should do a pgindent run fairly soon, so that people with patches
awaiting the next CF will have plenty of time to rebase them as necessary.
I don't want to do it right this minute, to avoid making trouble for the
several urgent patches we're trying to get done before Monday's beta1
wrap. But a
On 16. 05. 19 19:13, Andrey Borodin wrote:
>
>> 15 мая 2019 г., в 15:06, Andrey Borodin написал(а):
>>
>> Owners of AMD and ARM devices are welcome.
I've tested according to instructions at the test repo
https://github.com/x4m/test_pglz
Test_pglz is at a97f63b and postgres at 6ba500.
Hardware
I'm trying to convert SAP Hana procedures in PG and i'm not able to handle
below scenario in Postgres 11
Scenario: I want to pass a table (Multiple rows) to function and use it
inside as a temp table.
Sample Code:
create a table tbl_id (id int, name character varying (10));
insert few rows to tb
On Tue, May 14, 2019 at 12:24 AM Amit Langote
wrote:
> He did mention that cases where the nullable side is provably empty can be
> handled by simply returning the path of the non-nullable side with
> suitable projection path added on top to emit NULLs for the columns of the
> nullable-side. If w
On Fri, May 17, 2019 at 12:28 PM Lætitia Avrot
wrote:
> I do really appreciate that you took the time and your point of view is
> valuable to me.
>
>
I did not see your original mail from the 30th, we were talking about
apples and oranges. Sorry for the noise.
I have gone though that original ma
Hi,
I noticed that there is (another) oddity in commit aa09cd242f: in the
!fpinfo->use_remote_estimate mode, when first called for costing an
unsorted foreign scan, estimate_path_cost_size() computes
retrieved_rows, which is the estimated number of rows fetched from the
remote server, by these:
> 17 мая 2019 г., в 6:44, Michael Paquier написал(а):
>
> That's nice.
>
> From the numbers you are presenting here, all of them are much better
> than the original, and there is not much difference between any of the
> patched versions. Having a 20%~30% improvement with a patch is very
> nic
>
>
>> Maybe I wasn't clear enough. My point was using a connection string is
>> not documented. Here is PgBench documentation about dbname:
>>
>> > where *dbname* is the name of the already-created database to test in.
>> (You may also need -h, -p, and/or -U options to specify how to connect
>> to
On Fri, May 17, 2019 at 11:38 AM Lætitia Avrot
wrote:
> Maybe I wasn't clear enough. My point was using a connection string is not
> documented. Here is PgBench documentation about dbname:
>
> > where *dbname* is the name of the already-created database to test in.
> (You may also need -h, -p, a
Hi Juan,
Le ven. 17 mai 2019 à 11:26, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> a écrit :
>
> On Fri, May 17, 2019 at 9:16 AM Lætitia Avrot
> wrote:
>
>>
>> Given that, I think it would be a good thing to generalize the -d switch
>> (and maybe the --maintenance-db switch too).
>
On Fri, May 17, 2019 at 9:16 AM Lætitia Avrot
wrote:
>
> Given that, I think it would be a good thing to generalize the -d switch
> (and maybe the --maintenance-db switch too).
>
>
Just a couple of quick comments:
Some of those tools user --dbname as a long option.
Most of those tools al
On Fri, May 17, 2019 at 11:09 AM Michael Paquier wrote:
>
> On Wed, May 15, 2019 at 03:44:22PM +0900, Masahiko Sawada wrote:
> > I've attached new version patch that takes the way to let the backend
> > parser do all work.
>
> I was wondering how the error handling gets by not having the parsing
>
Hi all,
It seems my approach was quite candid because, of all postgres client
applications, some document usage of connection string whereas other don't.
Then, several ways of using connection strings are involved.
Here is a little digest:
| Postgres Client Application | Connection string syntax
70 matches
Mail list logo
