Safe operations?

I wish the documentation would include performance details, i.e. this operation is O(N) or O(1) relative to the number of rows. I found renaming a table was okay. How about renaming a column? Is it O(1) or proportional to the amount of data? Is there any documentation about this? Thanks Samuel

Re: Safe operations?

Thanks everyone for your prompt help. It sounds like a rename operation is almost never an issue unless you literally had millions of indexes. Thanks for all the follow on questions and answers, it was most helpful and interesting to learn a bit more about PG internals. On Mon, 13 Aug 2018 at 12:0

libpq pipelineing

Hello, Using the asynchronous interface of libpq, is it possible to pipeline multiple queries? i.e. PQsendQuery(query1) PQsendQuery(query2) followed by query1_results = PQgetResult(...) query2_results = PQgetResult(...) I tried it but got "another command is already in progress" error. So, m

Re: libpq pipelineing

/postgres/libpq-batch-mode.html However it seems to be abandoned. Kind regards, Samuel On Sat, 27 Jun 2020 at 16:15, David G. Johnston wrote: > > On Friday, June 26, 2020, Samuel Williams > wrote: >> >> Hello, >> >> Using the asynchronous interface of libpq, is it

Re: libpq pipelineing

> What about, as it says, sending multiple statements in a single sendQuery and > then polling for multiple results? I tried this, and even in single row streaming mode, I found that there are cases where the results would not be streamed until all the queries were sent. >From the users point of

Re: libpq pipelineing

Here is a short example: https://gist.github.com/ioquatix/2f08f78699418f65971035785c80cf18 It makes 10 queries in one "PQsendQuery" and sets single row mode. But all the results come back at once as shown by the timestamps. Next I'm planning to investigate streaming large recordsets to see if it

Re: libpq pipelineing

ingle logical set of results into lots of individual results. Maybe the statement about efficiency is incorrect, but it would be nice if you could incrementally stream a single result set more easily. On Sun, 28 Jun 2020 at 02:40, Tom Lane wrote: > > Samuel Williams writes: > > Here i

Re: libpq pipelineing

Samuel On Tue, 30 Jun 2020 at 02:06, Tom Lane wrote: > > Samuel Williams writes: > > Those methods don't seem to have an equivalent in libpq - you can use > > PQgetResult but it buffers all the rows. Using single row mode results > > in many results for each query (s

Re: libpq pipelineing

provides `mysql_fetch_row` which returns a `char **` per row. Requires only rows FFI calls. Does a similar method exist for libpq? e.g. `PGgetrow(index) -> char**` (array of strings, one for each column, may be nil to indicate null). Kind regards, Samuel On Tue, 30 Jun 2020 at 12:50, Samuel Willi

Partial index on JSON column

Hello I have a table with ~3 billion events. Of this, there are a small subset of events which match the following query: CREATE INDEX index_user_event_for_suggestion_notification ON public.user_event USING btree parameters ->> 'suggestion_id'::text))::integer), what) WHERE ((parameters ->>

Re: Partial index on JSON column

So, now that I think about it, maybe the way I'm using ::text is wrong. Any further advice is most appreciated. Kind regards, Samuel On Wed, 20 Feb 2019 at 10:14, Tom Lane wrote: > Samuel Williams writes: > > When I do this query: > > > EXPLAIN SELECT CO

Re: Partial index on JSON column

rows) Is there some way to directly use the integer value in the index with minimal type coercions? Thanks Samuel On Wed, 20 Feb 2019 at 10:24, Samuel Williams < space.ship.travel...@gmail.com> wrote: > Thanks for the quick reply Tom, > > I will try your advice. > > The r

Re: Partial index on JSON column

Thanks Tom, I did solve the problem by adding the null constraint for now, it's a quick solution, and I look forward to the future where this case is handled appropriately. On Wed, 20 Feb 2019 at 12:17, Tom Lane wrote: > I wrote: > > Try it like > > > EXPLAIN SELECT COUNT(*) FROM "user_event" WH

libpq read/write

I've been doing some profiling and I was surprised to see that libpq uses epoll when handling what essentially amounts to blocking reads/writes. https://github.com/postgres/postgres/blob/fc22b6623b6b3bab3cb057ccd282c2bfad1a0b30/src/backend/libpq/pqcomm.c#L207-L227 https://github.com/postgres/post

Re: libpq read/write

n the blocking case, that's correct behaviour. In the non-blocking case, I don't see how it's helpful to use epoll, because you should just return to the user right away. Thanks Samuel On Sun, 31 Mar 2019 at 03:17, Tom Lane wrote: > Samuel Williams writes: > > I've been